[swift-dev] [swift-evolution] There should be no reserved words (keywords) ?
Ted F.A. van Gaalen
tedvgiosdev at gmail.com
Fri Mar 4 07:40:50 CST 2016
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 at 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 Kashivskyy
>
>> Wiadomość napisana przez Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto: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-dev/attachments/20160304/c9daa3c5/attachment.html>
More information about the swift-dev
mailing list