There should be no reserved words (keywords) ?


(Ted van Gaalen) #1

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.


(Joe Groff) #2

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.


(Adrian Kashivskyy) #3

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? :stuck_out_tongue_winking_eye:

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


(Jordan Rose) #4

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`).


(Ted van Gaalen) #5

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? :stuck_out_tongue_winking_eye:

Pozdrawiam – Regards,
Adrian Kashivskyy

Wiadomość 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


(Joe Groff) #6

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.