folks, looking at the <v1 (stable)> milestone, the...
# github-workflows-kt
p
folks, looking at the v1 (stable) milestone, the only actionable task is Enforce named arguments in whole API (breaking change)! Regarding “whole”, I’m planning to do it for DSL functions like
job
or
uses
, but I was thinking of not doing this for literally every function/constructor, so also e.g. for data classes. If you have some thoughts on this, it’s the right moment to share them 🙂 I’m tentatively planning to do it for the v0.45.0, it will be a breaking change if you use positional args somewhere
K 1
it’s also a good moment to bring to my attention anything that must go into v1, even if it’s not tracked in the issues now
j
I’m like NikkyAI, I don’t understand how you force the consumer of the library to use named arguments. Is this an option I’m not aware of?
p
Are you asking how is it technically possible, or how I dare forcing the users to use the lib this way? :D
Yes, it's a hack. Or an idiom, depending on how you prefer to call it
I'm more interested in if it's a good idea. The biggest motivation behind it is not loosing the clarity of YAML when it comes to passing arguments in a form of a dictionary. If we want to encourage people to use the library, they cannot feel like they lose something, and they would by being able to use positional arguments. On the other side, the way I'd like to implement it doesn't give a clear error message, so it may cause confusion (more harm than good?)
So I'm still hesitating if we should do it, and if yes, to what extent
If ktlint supported kts files and had a rule for checking if kwargs are used, we could say it's a matter of preference of each person
j
That’s abolutely mind blowing, bravo
If you don’t mind, open an issue on yaml2kotlin when you do the change
p
@Nikky do you feel convinced it's a good idea?