I love these new features but I think it is an extremely unfortunate development to start introducing a multitude of magic function signatures, like callAsFunction, subscript[keyPath:], all the function builder stuff etc. And removing the attributes makes it downright bewildering..
It makes it much less clear why someone else's code that you are looking at works the way it does, and it makes it less discoverable for you when you make your own types, how would you ever guess that naming your function differently will produce a completely different effect?
I can only hope that the reason that the core team is moving away from the attributes is that they have some some longer term plan in mind that sorts all this out, like a macro system, better xcode integration or something else.
Barring that, I think a nicer approach than magic function names like callAsFunction would be to ADD an attribute at the relevant function definition, and then let you name it however you want:
@staticallyCall
func arbitrarilyNamedFunction(arg: String) -> Int { ... }
Another disadvantage with unattributed pseudo-protocols is that it's hard to find out more about them, even if a reader of the code suspects that there is something special going on. With normal protocols you can always click on the protocol name and read the documentation or at least the definition, but if there is no attribute there is nothing to click.
In short, there is a reason we don't have this syntax for init's and subscripts:
func init(value: T, otherValue: U) { ... }
func getAsSubscript(arg: T) -> U { ... }
They are functions calls that behave in very special ways, so they have a special syntax and even get different syntax highlighting. This makes it clearer that something special is going on. I haven't seen a compelling reason why this shouldn't apply to the newer features we're discussing here. Has one been given somewhere?
