Hello mates, why there is such a restriction on na...
# announcements
y
Hello mates, why there is such a restriction on named params? I mean, ofcourse Java cannot have named params, but I'm used to put param names for kinda not obvious consts, so I can view the file without IDE and see what this values mean. It may be useful if I could 'name' the param but keep its position, so after compilation param names will be just erased. UPD: Preventing misunderstand: • compiler should check that the order and names are correct • in runtime actually arg names should be erased
r
If the Java method took two String arguments then it could be deeply misleading - you could swap the order of the arguments in the call (or in the declaration if it was local) and it would all still compile with the wrong names.
Named arguments implies that the compiler is checking something for you when it isn’t.
y
Please read again my message, compiler should check that the order is correct. I saw this behaviour before, when after named arguments there are positional one, compiler requires correct positioning even for named args 🙂
For example, there is already order control
As I see, this was done exactly for cases when you want to directly tag const arguments
f
The problem would be if Java adds support for named arguments as it could require breaking the existing implementation. This would be bad for all if it would be the case. Have you considered comments? This way you could achieve what you want.
y
Yes, now I do this with comments I don't think Java can do such syntax that won't allow named arguments placed positionally, it could be just a dumb implementation, there is no way it will be
r
I’ve read it several times and I still don’t really understand what you want to be able to do but cannot do. Is it that you want to call methods from a lib not compiled with kotlinc using named params? Or that you want to mixed named and unnamed params?
y
I want to do stuff that I've shown on screenshot in topicstart, but without comments
Named comments in Java, but keeping positions, so it will be just a pointer in sources
r
The Java specification makes it optional whether parameter names are included as metadata when javac compiles a class, and by default they are not. So kotlinc can’t rely on them being there. And just because they are there in version 1.0.0 of a module doesn’t mean they will be there, or be the same, in version 1.0.1; most Java devs wouldn’t consider parameter names part of the binary compatibility of their lib (though as they are reachable by reflection if present they arguably should…).
y
That's a point, thanks!