I wanted to propose a very handy feature, overloading (also) based on named parameters. Basically this would compile:
proc foo(x : int) =
echo "In foo1\n"
proc foo(y : int) =
echo "In foo2\n"
foo(x = 2) # selects the first foo
To my surprise, this minimal example already works. Could it be the feature is already there? However, nothing is currently publicly documented.
Perhaps there's fear that the language would feel too complex. But in this case, resolution based on argument names is very intuitive, both for learning the language and during reading the code. Keeping it out doesn't really help one to understand the other rules better.
So I suggest to make the feature visible.
I'd rather leave this under-specified for the time being. "If in doubt, do nothing".
By not specifying the behavior, when the compiler changes in the future, behavior of code in the wild may well change. There will be no documented record of the prior behavior and perhaps no documentation of the new behavior, either.
Seems like a pretty big bummer for people who have stumbled upon this and "taken advantage". I doubt this is the only example of underspecified behavior in the compiler, but is it really worse to document future bugs with a warning? If we must punt, why not punt into the wind and maybe catch this sucker on its way back to us before it knocks someone's teeth out? :man_shrugging:
While we're waiting for a much more precise spec, Nim is defined by its implementation. If this feature will eventually be removed again, there will be a deprecation process. If this feature stays, it will find its way into the spec. This is not the first "accidentical" feature and it won't be the last by a mile.
Yeah, and I get that. Let me try a different tact. How about adding a test or two that relies upon this behavior, so that when someone decides to change the compiler, the new behavior can be gated and deprecation warnings can be issued. Or would you rather rely upon your memory?
Throw it in the experimental features doc, maybe? Since it's possible that it may be removed
That works, too, though I think the tests are probably the best solution. I'm sorry if my comment came across as snarky; I'm really just looking for a way to have a (however modestly) safe _option_ of using this feature (or code that uses it). To me, it's currently a loaded weapon.
Test + documented feature in the experimental manual please.
Most helpful comment
By not specifying the behavior, when the compiler changes in the future, behavior of code in the wild may well change. There will be no documented record of the prior behavior and perhaps no documentation of the new behavior, either.
Seems like a pretty big bummer for people who have stumbled upon this and "taken advantage". I doubt this is the only example of underspecified behavior in the compiler, but is it really worse to document future bugs with a warning? If we must punt, why not punt into the wind and maybe catch this sucker on its way back to us before it knocks someone's teeth out? :man_shrugging: