[Review] SE-0022: Referencing the Objective-C selector of a method

Evolution Announcements
21

Why not x.selector? This would still be more elegant than the second option, but would not cause ambiguity in the case that the type of x happens to have a property named “selector”.

Charles

···

On Jan 20, 2016, at 9:39 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 20, 2016, at 3:48 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 19, 2016, at 4:52 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 19, 2016, at 4:40 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:

Is there a well-defined meaning for `#` ?

Not yet.

What about selector(x)?

Objective-C selector formation is a *very* narrow feature to consider stealing one of our few underused sigils.

Actually, this isn’t that much different from “#available”, in the sense that it’s a special, compiler-supported expression type for which we don’t want to necessarily steal a keyword. What do others think about “selector”?

I think that selector is workable and fits into the model - it would be simple to implement and not cause unnecessary complexity in the implementation.

That said, I’m in favor of x.selector, or selector(x). The former seems more syntactically elegant if it is practical.

22

It seems like selector(x) would make it easier to get good autocompletion
(like Xcode's autocompletion of @selector(x) in ObjC doesn't insert
argument placeholders).

···

On Wed, Jan 20, 2016 at 9:39 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

That said, I’m in favor of x.selector, or selector(x). The former seems
more syntactically elegant if it is practical.

23

I guess we could give more targeted code completions inside selector(<code complete here>, only providing name completions for @objc entities.

  - Doug

···

On Jan 20, 2016, at 8:41 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org> wrote:

On Wed, Jan 20, 2016 at 9:39 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
That said, I’m in favor of x.selector, or selector(x). The former seems more syntactically elegant if it is practical.

It seems like selector(x) would make it easier to get good autocompletion (like Xcode's autocompletion of @selector(x) in ObjC doesn't insert argument placeholders).

24

+1 from me. At this point in Swift's evolution, the # feels like "invoke compiler substitution logic here".

Jordan

···

On Jan 20, 2016, at 19:56, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 20, 2016, at 7:39 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

On Jan 20, 2016, at 3:48 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 19, 2016, at 4:52 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 19, 2016, at 4:40 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:

Is there a well-defined meaning for `#` ?

Not yet.

What about selector(x)?

Objective-C selector formation is a *very* narrow feature to consider stealing one of our few underused sigils.

Actually, this isn’t that much different from “#available”, in the sense that it’s a special, compiler-supported expression type for which we don’t want to necessarily steal a keyword. What do others think about “selector”?

I think that selector is workable and fits into the model - it would be simple to implement and not cause unnecessary complexity in the implementation.

That said, I’m in favor of x.selector, or selector(x). The former seems more syntactically elegant if it is practical.

The latter gives us easy extensions like

  selector(getter: MyType.property)
  selector(setter: MyType.property)

selector is sorta growing on me.

25

We don't necessarily need to limit it to @objc entities; we can theoretically instantiate an ObjC method and selector for any method (or context-free closure, even) with an ObjC-compatible signature on demand.

-Joe

···

On Jan 21, 2016, at 11:08 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 20, 2016, at 8:41 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Wed, Jan 20, 2016 at 9:39 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
That said, I’m in favor of x.selector, or selector(x). The former seems more syntactically elegant if it is practical.

It seems like selector(x) would make it easier to get good autocompletion (like Xcode's autocompletion of @selector(x) in ObjC doesn't insert argument placeholders).

I guess we could give more targeted code completions inside selector(<code complete here>, only providing name completions for @objc entities.

26

I agree. Along those lines, we could consider renaming __LINE__ and friends to #LINE

-Chris

···

On Jan 21, 2016, at 4:13 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

I think that selector is workable and fits into the model - it would be simple to implement and not cause unnecessary complexity in the implementation.

That said, I’m in favor of x.selector, or selector(x). The former seems more syntactically elegant if it is practical.

The latter gives us easy extensions like

  selector(getter: MyType.property)
  selector(setter: MyType.property)

selector is sorta growing on me.

+1 from me. At this point in Swift's evolution, the # feels like "invoke compiler substitution logic here”.

27

Yes, we certainly could.

  - Doug

···

On Jan 21, 2016, at 4:14 PM, Joe Groff <jgroff@apple.com> wrote:

On Jan 21, 2016, at 11:08 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 20, 2016, at 8:41 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Wed, Jan 20, 2016 at 9:39 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
That said, I’m in favor of x.selector, or selector(x). The former seems more syntactically elegant if it is practical.

It seems like selector(x) would make it easier to get good autocompletion (like Xcode's autocompletion of @selector(x) in ObjC doesn't insert argument placeholders).

I guess we could give more targeted code completions inside selector(<code complete here>, only providing name completions for @objc entities.

We don't necessarily need to limit it to @objc entities; we can theoretically instantiate an ObjC method and selector for any method (or context-free closure, even) with an ObjC-compatible signature on demand.

28

+1 to setting __LINE__ (and friends) free of their unsightly upper snake case. They look like boa constrictors trying to digest a fully-swallowed keyword.

-- E

···

On Jan 21, 2016, at 10:04 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 21, 2016, at 4:13 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I think that selector is workable and fits into the model - it would be simple to implement and not cause unnecessary complexity in the implementation.

That said, I’m in favor of x.selector, or selector(x). The former seems more syntactically elegant if it is practical.

The latter gives us easy extensions like

  selector(getter: MyType.property)
  selector(setter: MyType.property)

selector is sorta growing on me.

+1 from me. At this point in Swift's evolution, the # feels like "invoke compiler substitution logic here”.

I agree. Along those lines, we could consider renaming __LINE__ and friends to #LINE

-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

29

+1 for selector(foo).

It emphasizes that this is primarily an Objective-C compatibility feature, not a first-class Swift feature (which the more visually appealing foo.selector would imply). Not to mention that with even moderately long method names, the postfix .selector gets buried visually. With selector(), on the other hand, a quick glance would always be enough to determine that we are accessing the selector, not the function itself.

···

On Jan 21, 2016, at 7:55 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 21, 2016, at 4:14 PM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:

On Jan 21, 2016, at 11:08 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 20, 2016, at 8:41 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Wed, Jan 20, 2016 at 9:39 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
That said, I’m in favor of x.selector, or selector(x). The former seems more syntactically elegant if it is practical.

It seems like selector(x) would make it easier to get good autocompletion (like Xcode's autocompletion of @selector(x) in ObjC doesn't insert argument placeholders).

I guess we could give more targeted code completions inside selector(<code complete here>, only providing name completions for @objc entities.

We don't necessarily need to limit it to @objc entities; we can theoretically instantiate an ObjC method and selector for any method (or context-free closure, even) with an ObjC-compatible signature on demand.

Yes, we certainly could.

  - Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

30

+1 to setting __LINE__ (and friends) free of their unsightly upper snake case. They look like boa constrictors trying to digest a fully-swallowed keyword.

Yeah, I totally agree. Actually, the proper spelling would simply be #line - after all, there’d be no need to shout any more…

-Chris

···

On Jan 21, 2016, at 9:17 PM, Erica Sadun <erica@ericasadun.com> wrote:

-- E

On Jan 21, 2016, at 10:04 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 21, 2016, at 4:13 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I think that selector is workable and fits into the model - it would be simple to implement and not cause unnecessary complexity in the implementation.

That said, I’m in favor of x.selector, or selector(x). The former seems more syntactically elegant if it is practical.

The latter gives us easy extensions like

  selector(getter: MyType.property)
  selector(setter: MyType.property)

selector is sorta growing on me.

+1 from me. At this point in Swift's evolution, the # feels like "invoke compiler substitution logic here”.

I agree. Along those lines, we could consider renaming __LINE__ and friends to #LINE

-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

31

Okay, you know this was coming: let's Groff this thing.

How about #(line) where you can decouple the specific compiler implementation bits from the keyword bits without hardcoding support, enabling implementation of, for example, #(runcible) for future Swift compiler substitution logic.

-- E

···

On Jan 21, 2016, at 10:19 PM, Chris Lattner <clattner@apple.com> wrote:

On Jan 21, 2016, at 9:17 PM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:

+1 to setting __LINE__ (and friends) free of their unsightly upper snake case. They look like boa constrictors trying to digest a fully-swallowed keyword.

Yeah, I totally agree. Actually, the proper spelling would simply be #line - after all, there’d be no need to shout any more…

-Chris

-- E

On Jan 21, 2016, at 10:04 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 21, 2016, at 4:13 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I think that selector is workable and fits into the model - it would be simple to implement and not cause unnecessary complexity in the implementation.

That said, I’m in favor of x.selector, or selector(x). The former seems more syntactically elegant if it is practical.

The latter gives us easy extensions like

  selector(getter: MyType.property)
  selector(setter: MyType.property)

selector is sorta growing on me.

+1 from me. At this point in Swift's evolution, the # feels like "invoke compiler substitution logic here”.

I agree. Along those lines, we could consider renaming __LINE__ and friends to #LINE

-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

32

What about other compiler hacks that begin with @? Like @objc ?

···

Sent from my iPhone

On 22 Jan 2016, at 05:19, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 21, 2016, at 9:17 PM, Erica Sadun <erica@ericasadun.com> wrote:

+1 to setting __LINE__ (and friends) free of their unsightly upper snake case. They look like boa constrictors trying to digest a fully-swallowed keyword.

Yeah, I totally agree. Actually, the proper spelling would simply be #line - after all, there’d be no need to shout any more…

-Chris

-- E

On Jan 21, 2016, at 10:04 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 21, 2016, at 4:13 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

I think that selector is workable and fits into the model - it would be simple to implement and not cause unnecessary complexity in the implementation.

That said, I’m in favor of x.selector, or selector(x). The former seems more syntactically elegant if it is practical.

The latter gives us easy extensions like

  selector(getter: MyType.property)
  selector(setter: MyType.property)

selector is sorta growing on me.

+1 from me. At this point in Swift's evolution, the # feels like "invoke compiler substitution logic here”.

I agree. Along those lines, we could consider renaming __LINE__ and friends to #LINE

-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

33

If you're going to bring me into it…I would prefer coalescing all these __FILE__, __LINE__, etc. things into one #sourceLocation structure. If you want one source-location-related thing, you tend to want the others, and you also want to be able to forward the source location info easily through the depths of your assertion/logging framework.

-Joe

···

On Jan 21, 2016, at 9:25 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Okay, you know this was coming: let's Groff this thing.

How about #(line) where you can decouple the specific compiler implementation bits from the keyword bits without hardcoding support, enabling implementation of, for example, #(runcible) for future Swift compiler substitution logic.

34

Okay, you know this was coming: let's Groff this thing.

How about #(line) where you can decouple the specific compiler implementation bits from the keyword bits without hardcoding support, enabling implementation of, for example, #(runcible) for future Swift compiler substitution logic.

The compiler can parse

  #identifier

or

  #identifier(balanaced-set-of-tokens)

without knowing what the identifier is going to be. One could imagine that as a way to, say, expand a macro in some as-yet-undesigned macro system. #available, selector, #line, #column, etc. are merely short-term hacks until such a macro system gets designed.

I’m supportive of sharpening the boa constrictors to #line, #column, etc., but I’m too design-fatigued to write it up. Any takers?

  - Doug

···

On Jan 21, 2016, at 9:25 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

-- E

On Jan 21, 2016, at 10:19 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

On Jan 21, 2016, at 9:17 PM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:

+1 to setting __LINE__ (and friends) free of their unsightly upper snake case. They look like boa constrictors trying to digest a fully-swallowed keyword.

Yeah, I totally agree. Actually, the proper spelling would simply be #line - after all, there’d be no need to shout any more…

-Chris

-- E

On Jan 21, 2016, at 10:04 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 21, 2016, at 4:13 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I think that selector is workable and fits into the model - it would be simple to implement and not cause unnecessary complexity in the implementation.

That said, I’m in favor of x.selector, or selector(x). The former seems more syntactically elegant if it is practical.

The latter gives us easy extensions like

  selector(getter: MyType.property)
  selector(setter: MyType.property)

selector is sorta growing on me.

+1 from me. At this point in Swift's evolution, the # feels like "invoke compiler substitution logic here”.

I agree. Along those lines, we could consider renaming __LINE__ and friends to #LINE

-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

35

-- E

···

On Jan 21, 2016, at 10:44 PM, Joe Groff <jgroff@apple.com> wrote:

On Jan 21, 2016, at 9:25 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Okay, you know this was coming: let's Groff this thing.

How about #(line) where you can decouple the specific compiler implementation bits from the keyword bits without hardcoding support, enabling implementation of, for example, #(runcible) for future Swift compiler substitution logic.

If you're going to bring me into it…I would prefer coalescing all these __FILE__, __LINE__, etc. things into one #sourceLocation structure. If you want one source-location-related thing, you tend to want the others, and you also want to be able to forward the source location info easily through the depths of your assertion/logging framework.

-Joe

36

If no one who is actually qualified jumps in, I can take a stab at starting it.

-- E, heading off to bed, and dreaming of screaming snake-case keywords on small planets with small Swift-powered volcanos for cooking breakfast

···

On Jan 21, 2016, at 10:47 PM, Douglas Gregor <dgregor@apple.com> wrote:

On Jan 21, 2016, at 9:25 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Okay, you know this was coming: let's Groff this thing.

How about #(line) where you can decouple the specific compiler implementation bits from the keyword bits without hardcoding support, enabling implementation of, for example, #(runcible) for future Swift compiler substitution logic.

The compiler can parse

  #identifier

or

  #identifier(balanaced-set-of-tokens)

without knowing what the identifier is going to be. One could imagine that as a way to, say, expand a macro in some as-yet-undesigned macro system. #available, selector, #line, #column, etc. are merely short-term hacks until such a macro system gets designed.

I’m supportive of sharpening the boa constrictors to #line, #column, etc., but I’m too design-fatigued to write it up. Any takers?

  - Doug

-- E

On Jan 21, 2016, at 10:19 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

On Jan 21, 2016, at 9:17 PM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:

+1 to setting __LINE__ (and friends) free of their unsightly upper snake case. They look like boa constrictors trying to digest a fully-swallowed keyword.

Yeah, I totally agree. Actually, the proper spelling would simply be #line - after all, there’d be no need to shout any more…

-Chris

-- E

On Jan 21, 2016, at 10:04 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 21, 2016, at 4:13 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I think that selector is workable and fits into the model - it would be simple to implement and not cause unnecessary complexity in the implementation.

That said, I’m in favor of x.selector, or selector(x). The former seems more syntactically elegant if it is practical.

The latter gives us easy extensions like

  selector(getter: MyType.property)
  selector(setter: MyType.property)

selector is sorta growing on me.

+1 from me. At this point in Swift's evolution, the # feels like "invoke compiler substitution logic here”.

I agree. Along those lines, we could consider renaming __LINE__ and friends to #LINE

-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

37

+1

···

on Thu Jan 21 2016, Joe Groff <swift-evolution@swift.org> wrote:

On Jan 21, 2016, at 9:25 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Okay, you know this was coming: let's Groff this thing.

How about #(line) where you can decouple the specific compiler
implementation bits from the keyword bits without hardcoding
support, enabling implementation of, for example, #(runcible) for
future Swift compiler substitution logic.

If you're going to bring me into it…I would prefer coalescing all
these __FILE__, __LINE__, etc. things into one #sourceLocation
structure.

--
-Dave

38

The downside is that this becomes Yet Another Compiler-Known Type and Yet Another Thing In the Standard Library. All the current fields are string literals and integer literals.

Jordan

···

On Jan 21, 2016, at 21:44, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 21, 2016, at 9:25 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Okay, you know this was coming: let's Groff this thing.

How about #(line) where you can decouple the specific compiler implementation bits from the keyword bits without hardcoding support, enabling implementation of, for example, #(runcible) for future Swift compiler substitution logic.

If you're going to bring me into it…I would prefer coalescing all these __FILE__, __LINE__, etc. things into one #sourceLocation structure. If you want one source-location-related thing, you tend to want the others, and you also want to be able to forward the source location info easily through the depths of your assertion/logging framework.

39

What about other compiler hacks that begin with @? Like @objc ?

@ is for attributes. This is an expression.

-Chris

···

On Jan 22, 2016, at 12:03 PM, James Campbell <james@supmenow.com> wrote:

Sent from my iPhone

On 22 Jan 2016, at 05:19, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 21, 2016, at 9:17 PM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:

+1 to setting __LINE__ (and friends) free of their unsightly upper snake case. They look like boa constrictors trying to digest a fully-swallowed keyword.

Yeah, I totally agree. Actually, the proper spelling would simply be #line - after all, there’d be no need to shout any more…

-Chris

-- E

On Jan 21, 2016, at 10:04 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 21, 2016, at 4:13 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I think that selector is workable and fits into the model - it would be simple to implement and not cause unnecessary complexity in the implementation.

That said, I’m in favor of x.selector, or selector(x). The former seems more syntactically elegant if it is practical.

The latter gives us easy extensions like

  selector(getter: MyType.property)
  selector(setter: MyType.property)

selector is sorta growing on me.

+1 from me. At this point in Swift's evolution, the # feels like "invoke compiler substitution logic here”.

I agree. Along those lines, we could consider renaming __LINE__ and friends to #LINE

-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

40

What about property attributes? how come some attributes don't have a @
like dynamic or lazy and others do like @objc.

···

*___________________________________*

*James⎥Lead Engineer*

*james@supmenow.com <james@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Fri, Jan 22, 2016 at 9:36 PM, Chris Lattner <clattner@apple.com> wrote:

On Jan 22, 2016, at 12:03 PM, James Campbell <james@supmenow.com> wrote:

What about other compiler hacks that begin with @? Like @objc ?

@ is for attributes. This is an expression.

-Chris

Sent from my iPhone

On 22 Jan 2016, at 05:19, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:

On Jan 21, 2016, at 9:17 PM, Erica Sadun <erica@ericasadun.com> wrote:

+1 to setting __LINE__ (and friends) free of their unsightly upper snake
case. They look like boa constrictors trying to digest a fully-swallowed
keyword.

Yeah, I totally agree. Actually, the proper spelling would simply be
#line - after all, there’d be no need to shout any more…

-Chris

-- E

On Jan 21, 2016, at 10:04 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:

On Jan 21, 2016, at 4:13 PM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote:

I think that selector is workable and fits into the model - it would be
simple to implement and not cause unnecessary complexity in the
implementation.

That said, I’m in favor of x.selector, or selector(x). The former seems
more syntactically elegant if it is practical.

The latter gives us easy extensions like

selector(getter: MyType.property)
selector(setter: MyType.property)

selector is sorta growing on me.

+1 from me. At this point in Swift's evolution, the # feels like "invoke
compiler substitution logic here”.

I agree. Along those lines, we could consider renaming __LINE__ and
friends to #LINE

-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution