[swift-evolution] Colon vs. equals

[Alex Hoppen]

Same for me. I would like to see the syntax changed for @available but think that we should stick to the colon for dictionaries and function calls.

- Alex

> On 08 Feb 2016, at 11:42, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I like the current usage of the colon as it is very readable and unobstrusive.
> 
> I agree that @available should use colons, too.
> 
> -Thorsten
> 
> 
> Am 07. Februar 2016 um 20:19 schrieb ilya via swift-evolution <swift-evolution at swift.org>:
> 
>> I know it's a bit late to the party :) but I have to disagree with the original premise.
>> The colon in the dictionary doesn't really separate names and values, it separates values and values:
>> 
>> ["something" + "else" : 1 + 2] 
>> 
>> is a perfectly valid dictionary that doesn't read nor write anything by name. In other words, there are no lhs-expressions there and that's ok.
>> 
>> We use = to rebind the names or, more generally, call setters, and when we do this an lhs-expression is required, well, on the left side of an assignment operator. This is in no way related to what happens with the dictionary. 
>> 
>> The situation is different with function parameters. We don't really pass a dictionary; if we did, we'd use something like myFunc("":foo, "bar": baz) as a syntax. 
>> 
>> One can attempt to read the syntax as binding names that the function can use as parameters, but this doesn't really work either: we only know the parameter's external names and this binding doesn't "leak" into the original scope. So if we are thinking about function call as an assignment, then it should be in an extremely short-lived scope contained within a function call. It doesn't look like this view will bring us any benefits. 
>> 
>> I think it's best to imagine the colon in function calls as simply a third punctuation symbol. We do need to select a simple, readily available symbol that cannot be easily mixed with colon-inside-the-dictionary and regular-assignment-symbol, yet is still instantly recognisable. Reusing the colon is a reasonable compromise, although => would also work (and I wish it was given serious consideration). 
>> 
>> Though I agree that it seems a bit excessive to have a separate syntax for @available's parameters.
>> 
>> Ilya.
>>  
>> 
>> On Sat, Feb 6, 2016 at 12:27 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> This is perhaps a bit nitpicky, but I've noticed that Swift sometimes uses colon to separate names and values, and sometimes uses equals. It's vaguely maddening.
>> 
>> What do I mean? Well, our language has this:
>> 
>>         myFunc(foo, bar: baz)
>> 
>> But it also has:
>> 
>>         @available(iOS, introduced=7.0, deprecated=8.0)
>> 
>> You create a dictionary like this:
>> 
>>         let dict = ["key": "value"]
>> 
>> But you set it like this:
>> 
>>         dict["key"] = "value"
>> 
>> Is there some principle here? The @available case seems particularly strange to me, because those values read strongly like parameters to me.
>> 
>> --
>> Brent Royal-Gordon
>> Architechies
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160208/b38a042c/attachment.html>