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`).
-Joe
On Mar 4, 2016, at 4:43 AM, Ted F.A. van Gaalen via swift-evolution <swift-evolution@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.
func if<T>(@autoclosure condition: () -> Bool, @noescape closure: () -> T) -> T? {
if(!condition()) {
return closure()
}
return nil
}if(2 + 2 == 4) {
return 5
}
In the world without reserved keywords, what should the above code do? 
Pozdrawiam – Regards,
Adrian Kashivskyy
Wiadomość napisana przez Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> w dniu 04.03.2016, o godz. 13:43:
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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
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.
Jordan
On Mar 4, 2016, at 10:12, Joe Groff via swift-dev <swift-dev@swift.org> wrote:
On Mar 4, 2016, at 4:43 AM, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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`).
Hi Adrian
in this case -assuming for a moment a PL/1 compiler knows Swift -
if would accept the if() as a function, because
you wished to declare it that way.
however then flagged the intended? func usage:
if (2+2 == 4)
as ambiguous , because the compiler is unable to determine from the context
in what way ‘if’ is used here.
In effect telling the programmer not to do “weird things” :o)
It can be notoriously difficult to implement this in a compiler,
so I am probably asking too much, also because
one should try to avoid confusion and avoid using
reserved words of other things.
I had this problem some time ago when using ‘and:’ as a Swift function parameter
like so
func rangeBetween(a:Float, and: b) -> [Float]
which worked ok btw in the first versions of Swit
TedvG
On 04.03.2016, at 14:03, Adrian Kashivskyy <adrian.kashivskyy@me.com> wrote:
func if<T>(@autoclosure condition: () -> Bool, @noescape closure: () -> T) -> T? {
if(!condition()) {
return closure()
}
return nil
}if(2 + 2 == 4) {
return 5
}In the world without reserved keywords, what should the above code do?
Pozdrawiam – Regards,
Adrian KashivskyyWiadomość napisana przez Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> w dniu 04.03.2016, o godz. 13:43:
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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
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
On Mar 7, 2016, at 1:26 PM, Jordan Rose <jordan_rose@apple.com> wrote:
On Mar 4, 2016, at 10:12, Joe Groff via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
On Mar 4, 2016, at 4:43 AM, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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.