Parameter names in subscripts

[MikeNeirinck]

In my opinion the naming of parameters is confusing. Why?
When you want to omit the parameter name the declaration looks as follows: subscript(parameter: String) -> String. Calling the subscript is done as follows: instance["some String value"]. Thinking of functions the declaration should be subscript(_ parameter: String) for this case. Declaring subscript(parameter: String) -> String however also results in the omittance of the parameter name.

If naming was done the same as it is in functions the call would be instance[parameter: "some String value"]. This is not the case however. The only way to get the latter call is declaring subscript(parameter parameter: String) -> String.

This leads to confusion. So we ought to harmonize the naming in line with functions.

[DevAndArtist (Adrian Meister)]

I think this pitch will lead to nowhere. Not saying that it shouldn't, I'm really sad about this decision myself.

I also pitched this once and it seems that source compatibility wins over language consistency.

[Pitch] Align label behavior for subscripts

This is probably something additional and it might already have been discussed here somewhere, I apologize if I missed that talk. The rule for parameter labels on functions was fixed in Swift, but now it kinda feels odd to have a different pair of rules for subscripts (at least it does feel odd to me). // Is fine when the names are different subscript(externalName internalName: ParamType) -> ElementType {     get { … }     set { … } } something[externalName: …] // We had this with functi…

[Tino]

Probably most subscripts take a single parameter without label, so the current behavior is the best fit when seen in isolation.
Consistency might be better with the pitched change, but imho the rule never causes trouble (while I had to lookup several times wether it is -> String or : String...)