Paul,
just to clarify, its not so much that we change method signatures for Silver. It’s just that with Elements (all four languages really), method parameters can have optional name prefixes, and if they are so defined, those prefixes need to be provided. Essentially, those prefixes become part f the name of the method.
When you declare your own methods, you can choose to give prefixes to the parameters, nor not, and that defines how they would be called (from Swift, and from our Java compiler, as well; because we need to mangle the actual platform-level names when prefixes are used, methods with prefix will not look pretty when people will try to call them from Oracle’s Java compiler (or, on .NET, from Microsoft’s C# compiler).
I take it that this is about your own classes — you want to build your code as a .jar, and people that use it from Swift see nice Swiftifed names with prefixes, but people using the Java language to use the same class will see simple method names without prefixes, right?
That’s gonna be tricky. First question ill the people writing against your code from the Java language use our Java compiler, or Oracle’s
If the former, the best option is to just have them embrace prefixes (or multi-part method names, as we call emO. if you define, say
func xyz(_ one: String, two: Int)
this becomes
void xyz(String) two(String)
in our java compiler.
Alternatively you could just define two versions of the method (one could forward the other), one with a unprefixed signature. the Oracle Java users can just ignore the under-scored mangled ones.
Does this make sense?