[swift-evolution] [swift-dev] There should be no reserved words (keywords) ?

[Joe Groff]

> On Mar 7, 2016, at 1:26 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
>> 
>> On Mar 4, 2016, at 10:12, Joe Groff via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> 
>>> 
>>> On Mar 4, 2016, at 4:43 AM, Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Hello, 
>>> 
>>> reserved words:
>>> 
>>> In short:
>>>                  -=  there should be none =-
>>> 
>>> A compiler should have enough intelligence 
>>> to determine from the statement’s context 
>>> if words are used as a keywords or not.  
>>> 
>>> Like e.g. in PL/1 as I posted here before.
>>> 
>>> What’s your opinion?
>>> 
>>> Kind Regards, Ted.
>> 
>> We're getting close. We already allow arbitrary keywords as argument labels, and Doug has proposed allowing them after `.` accesses as well, so you can freely define and use methods named foo.default(in:if:else:). Keywords at that point only interfere with the "root" identifier of a chain, and you could introduce module, type, or instance qualification to avoid that problem (saying Module.default instead of `default`).
> 
> Whenever possible, we should endeavour to make source code readable by humans; being easy for the compiler is nice, but shouldn't be a primary goal.
> 
> Humans reading code will have an easier time if identifiers consistently refer to the same thing. This doesn't always happen—methods on different types, methods shadowing top-level functions, etc—but in general we should not encourage people to change the meaning of symbols.
> 
> -1 from me.

In the places where we do or plan to allow generalized keyword access, there isn't really anything else that makes sense than an identifier, so human readability doesn't strike me as an issue.

-Joe

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