[Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier


(Chris Lattner) #1

Hello Swift community,

The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier" begins now and runs through October 18. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager


(Hooman Mehr) #2

+1. I am in favor of keeping and documenting single dollar sign as a valid identifier.

I personally find it very convenient to have it as a valid identifier, although I don’t use Dollar library.

···

On Oct 14, 2016, at 12:59 PM, Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier" begins now and runs through October 18. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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


(Felipe Cypriano) #3

-1

I agree with the motivations to remove it.

···

On Fri, Oct 14, 2016, at 12:59, Chris Lattner via swift-evolution wrote:

Hello Swift community,

The review of "SE-0144: Allow Single Dollar Sign as a Valid
Identifier"
begins now and runs through October 18. The proposal is
available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md

Reviews are an important part of the Swift evolution process.
All reviews
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction
of Swift.
When writing your review, here are some questions you might want to
answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a
  change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar
  feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick
  reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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


(Lily Ballard) #4

  * What is your evaluation of the proposal?

-1. I agree with the reasons for removal, and do not consider the existence of a single library that depends on undocumented behavior to be sufficient reason for this change.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick reading.

-Kevin Ballard

···

On Fri, Oct 14, 2016, at 12:59 PM, Chris Lattner wrote:


(Matthew Johnson) #5

  * What is your evaluation of the proposal?

-1. I don’t like the idea of a user-defined `$` identifier. I agree with the reasons for removing it. If it is allowed as a user-defined entity it feels an operator is more appropriate. Otherwise, it could be reserved as a special, compiler-defined identifier (like that `$n` closure argument identifiers) for future use in some way.

  * Is the problem being addressed significant enough to warrant a change to Swift?

No, removing it was a good decision.

  * Does this proposal fit well with the feel and direction of Swift?

No. Despite it’s use in some popular libraries it has always seemed out of place as an identifier to me.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have used JavaScript libraries that use this convention. I don’t think this style of library design is a good fit for Swift.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick read.

···

More information about the Swift evolution process is available at


(Robert Widmann) #6

As the author of the patch that introduced this and the patch that will come out of this discussion, I have no problems one way or the other. Just bear in mind that if $ is an identifier head character then it cannot be used in operators - something I have a library with a vested interest in.

~Robert Widmann

···

On Oct 14, 2016, at 3:59 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier" begins now and runs through October 18. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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


#7

* What is your evaluation of the proposal?

-1. If it were a valid identifier, $ would look even more confusing when used as a type name. I’d rather see $ used as an operator.

* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?

No.

* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I don’t think this is a Swifty style.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More than a quick reading.

-Richard

···

On Oct 14, 2016, at 14:59, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier" begins now and runs through October 18. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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


(Charles Srstka) #8

Hello Swift community,

The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier" begins now and runs through October 18. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

* What is your evaluation of the proposal?

-1. What is the point of this?

* Is the problem being addressed significant enough to warrant a change to Swift?

The “problem” seems to be that one specific library misused a character that was not documented to be legal in an identifier. The solution would seem to be to fix the library, not change the language.

* Does this proposal fit well with the feel and direction of Swift?

No, it does not. $ by itself looks far more like an operator than an identifier, and $ as the beginning of an identifier conflicts with the special $0, $1, etc. keywords that are already used by Swift.

* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

The discussion of identifiers beginning with $ brings to mind Perl and similar scripting languages, in which scalar variables look like $foo, $bar, etc. I imagine that this is why $ was chosen for the $0, $1, etc. keywords. As a result, when seeing something like $foo in the language, one’s mind tends to interpret this as a variable named “foo” with the $ doing something to it, describing something about it, or something similar.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the proposal, read the thread.

Charles

···

On Oct 14, 2016, at 2:59 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:


(Chéyo Jiménez) #9

Hello Swift community,

The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier" begins now and runs through October 18. The proposal is available here:

   https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

   https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

   * What is your evaluation of the proposal?

-1

   * Is the problem being addressed significant enough to warrant a change to Swift?

No. $0 $1

   * Does this proposal fit well with the feel and direction of Swift?

No. $ and _ are popular in JS but I think the functionality of theses libraries should be moved to extensions to the specific types in Swift .

   * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

JS. jQuery

   * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick study.

···

On Oct 14, 2016, at 12:59 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
More information about the Swift evolution process is available at

   https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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


(Daniel Müllenborn) #10

* What is your evaluation of the proposal?
-1
* Does this proposal fit well with the feel and direction of Swift?
Not at all.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Not much, as it just does not appeal to me.


(Haravikk) #11

  * What is your evaluation of the proposal?

Not in favour, sorry. While I've used this kind of pattern in Javascript I just don't see what it really adds compared to a more explicit name. As a general rule I prefer everything to be explicitly named except where a case is genuinely trivial (like the dollar syntax for closure arguments).

  * Is the problem being addressed significant enough to warrant a change to Swift?

If it had more benefits maybe, but I just don't see them.

  * Does this proposal fit well with the feel and direction of Swift?

No, I think that allowing the dollar sign could be confusing alongside dollar sign variables in closures, and I feel that Swift is better being explicit where possible.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

It's similar to a lot of Javascript libraries that use the dollar sign for values, but I've never felt that I was really gaining anything significant by using it as a variable name.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick read.

···

On 14 Oct 2016, at 20:59, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:


(Russ Bishop) #12

-1 from me.

The library in question was exploiting a bug in the compiler. I went and checked the officially published Swift 1.0 grammar and “$” is not a valid identifier.

I’m sympathetic to the argument that the behavior shipped in three major versions but ultimately all this does is create an opportunity for cute tricks.

Russ

···

On Oct 14, 2016, at 12:59 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier" begins now and runs through October 18. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?


(Georgios Moschovitis) #13

* What is your evaluation of the proposal?

-1

The only use case of ‘$’ would be in short funny swift examples or in a playground, e.g. as a variable for a monetary amount. Similar to the emojis used as variables in the wild.

But then, you could just use the $emoji…

* Is the problem being addressed significant enough to warrant a change to Swift?

no

* Does this proposal fit well with the feel and direction of Swift?

no

* If you have used other languages or libraries with a similar feature, how do you feel that this proposal

compares to those?

js/jQuery

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

quick read


(Jacob Bandes-Storch) #14

Proposal link:

        https://github.com/apple/swift-evolution/blob/master/propo
sals/0144-allow-single-dollar-sign-as-valid-identifier.md

        * What is your evaluation of the proposal?

-1.

The proposal does not actually provide motivation for keeping $ beyond "the
Dollar library already uses it".

A more Swifty way for a library to introduce these operations would be with
extensions. Here are some suggestions, based off the first several
operations described in the library's readme:

$.at → convenience subscript(Index...) for Collection
$.chunk → convenience function for Sequence
$.compact → flatMap{$0}
$.contains → already exists as Sequence.contains
$.cycle → convenience function for Collection
$.difference → convenience function on Collection, or just use Set
operations, or filter
$.each → exists as Sequence.forEach
$.every → extension on Sequence
$.factorial → convenience method or postfix operator for Integer
$.fetch → convenience function on Collection
and so on.

It looks like the author's Cent <https://github.com/ankurp/Cent> library is
already taking this approach.

        * Is the problem being addressed significant enough to warrant a
change to Swift?

Yes, but the change has already been made: removing $ as a valid identifier
:wink:

        * Does this proposal fit well with the feel and direction of Swift?

Not really. If anything, IMO, the dollar sign feels more like an operator
character. (However, it's probably here to stay in identifiers because of
closure parameters and LLDB variables.)

        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?

The Dollar library resembles the style of JavaScript libraries such as
jQuery or Underscore, but that isn't a positive thing in my mind — as
mentioned above, the Swift way of doing things is different.

        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

Thorough reading of the proposal; brief glance at the library's readme on
GitHub. Lots of time thinking about operator & identifier characters for a
forthcoming proposal.


(Fons Rademakers) #15

  * What is your evaluation of the proposal?

-1

  * Is the problem being addressed significant enough to warrant a change to Swift?

no

  * Does this proposal fit well with the feel and direction of Swift?

no

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

perl feeling, don’t like it as part of a modern clear and concise language.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

quick reading.

···

More information about the Swift evolution process is available at

--------------------------------------------------------------------------
Dr. Fons Rademakers CERN - European Organization for Nuclear Research
Chief Research Officer 1211 Geneve 23, Switzerland
CERN openlab Tel: +41227679248 Mobile: +41754113742
--------------------------------------------------------------------------


(Tony Allevato) #16

Hello Swift community,

The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier"
begins now and runs through October 18. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of Swift.
When writing your review, here are some questions you might want to answer
in your review:

        * What is your evaluation of the proposal?

-1. Since the dollar sign is used as a prefix for unnamed closure
arguments, allowing it to be used by itself as a user-defined identifier
would be odd and potentially confusing. It's also, IMO, a useless
standalone identifier because it provides zero self-documentation as to its
purpose. Reserving "$" means that users will know that when they see it, it
refers to something special and intrinsic to the language.

        * Is the problem being addressed significant enough to warrant a
change to Swift?

No. The library using it is using an undocumented and accidental "feature"
that was removed for sound reasons and the language shouldn't change to
support that.

        * Does this proposal fit well with the feel and direction of Swift?

No. The library that is motivating the change is trying to shoehorn
Javascript patterns into Swift; the language shouldn't be designed around
it. The author's own Cent library, which uses extensions, is a much more
Swift-appropriate way to tackle what the problem he's trying to solve.

        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?

Java and Javascript allow $ as a standalone identifier. I don't see a
reason to follow that in Swift, though.

        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

Read the proposal.

···

On Fri, Oct 14, 2016 at 1:00 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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


#17

* What is your evaluation of the proposal?

+1
We should do the best to avoid source breaking change in Swift4.
https://github.com/ankurp/Dollar is used in so many projects.
I believe removing this might discourage them from using Swift.

        * Is the problem being addressed significant enough to warrant a
change to Swift?

Yes

        * Does this proposal fit well with the feel and direction of Swift?

No. Also, I personally dislike symbol only identifier.
But IMO, we have to compromise this.

      * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

Quick reading.

···

2016-10-15 4:59 GMT+09:00 Chris Lattner via swift-evolution < swift-evolution@swift.org>:

Hello Swift community,

The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier"
begins now and runs through October 18. The proposal is available here:

        https://github.com/apple/swift-evolution/blob/master/proposa
ls/0144-allow-single-dollar-sign-as-valid-identifier.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of Swift.
When writing your review, here are some questions you might want to answer
in your review:

        * What is your evaluation of the proposal?
        * Is the problem being addressed significant enough to warrant a
change to Swift?
        * Does this proposal fit well with the feel and direction of Swift?
        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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


(Brent Royal-Gordon) #18

  https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md

  * What is your evaluation of the proposal?

I know this is cutting against the grain, but I'm in favor.

I don't think the Dollar library is a good design, but I think there *are* good designs which could use an extremely short, distinctive identifier like `$`. These would be cases where there is a single, specific object, operation, or type which is absolutely central to the problem domain. jQuery is a good example of this: it is used in browsers, where DOM manipulation is such a big part of what you're doing that an extremely shorthanded syntax is appropriate. Other examples might include parsing or generating strings. In general, anything where a Swift file is effectively "embedded" or acting as a "plugin" might benefit from `$`.

Certainly that is not most Swift code, but this is a harmless change when you don't need it, and a helpful change when you do. And certainly code using it may be a little sloppy unless there's preprocessing involved, but sometimes a sloppy solution is the most expressive one.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Maybe. It certainly is possible to design around it by switching to a single identifier character, but few of those stand out in the same way `$` does.

  * Does this proposal fit well with the feel and direction of Swift?

I think it does. Swift disfavors boilerplate, and the places I imagine `$` ought to be used are those where a longer name would introduce unacceptable amounts of boilerplate.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

`$` is certainly a rather popular identifier in Javascript.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Not much more than a glance.

···

On Oct 14, 2016, at 12:59 PM, Chris Lattner <clattner@apple.com> wrote:

--
Brent Royal-Gordon
Architechies


(Benjamin Spratling) #19

Howdy,
  It seems the main question in discussing this proposal is “If $0, $1, $2, $3 are automatic closure parameters, then what is “$”?”. Another thing that has also recently come to my attention that Swift does not have a “result of previous expression” magic identifier as some functional languages do. Combine this with my difficulty in creating closures which automatically bind weakly to the variable, and I’m looking at a potential meaning for “$” consistent with all of these goals.

First off, I don’t like the “$0, $1, $2, …” feature, but I can respect it. I mainly don’t like it because in English “$” is defined as “dollar”, not “magic variable number _”. However, it appears that in Swift, “$” really does mean “magic variable number _”, and some developers find it very useful.

I’m not looking to routinely violate the law of Demeter, but occasionally in data conversion, it’s really unavoidable. Sometimes, I need to convert to a type with a non-optional argument, but my argument is Optional. Here, for instance:

struct XMLNode {
  var attributes:[String:String]
}

struct Note {
  /// half-steps from middle-C, nil means the note is a rest
  var pitch:Int?
  //more properties
  init?(xmlNode: XMLNode) {
    if let pitchString:String = xmlNode.attributes[“pitch”], let pitchInt:Int = Int(pitchString) {
      pitch = pitchInt
    }
    //more code
  }
}

I could go write an extension on String to provide a computed integer property, but I’m not just talking about one case, I’m talking about all cases where we convert to types in this way.

If “$” meant “identifier of result of previous expression”, I could write:

init?(xmlNode: XMLNode) {
  pitch = xmlNode.attributes[“pitch”]?Int($)
  //more code
}

instead. Much cleaner.

Now, in my mind the first question is: “don’t I need another operator after the “?” ? “ And that got me thinking about unowned/weak capture in closures and UndoManager blocks. If the reference is captured separately from the actions on the reference, then strong/weak/unowned really isn’t an argument for those cases. It’s like I want an autoclosure that takes 1 instead of 0 arguments, the 1 generic value from the previous expression, which, incidentally would be represented by “$”—if it were explicitly referenced. The optional chaining operator right now, as I understand it, is compiler magic. But what if there were a language construct for such features as there is for optimized evaluation with ??, &&, and || ? It would allow me to create my own “?”-like behaviors.

Which operator it is, I don’t much care; I am looking closely at “\”. Finally, there is a difference between a 1-argument auto closure that acts as if it continued an expression, i.e. _?._ and one which places the previous result as an argument into a self-contained expression. But if the leading-dot, i.e. “.intValue”, syntax is itself just syntactic sugar for writing “$.intValue”, then there really isn’t a difference.

So the chaining optional operator becomes defined in the language as:

nocapture operator ? : WhateverPrecedenceGroup

infix func ?<LReturnType, RReturnType>(lhs:@autoclosure()->(LReturnType?), rhs:@autoclosure (LReturnType)->(RReturnType))-> RReturnType? {
  guard let lhs = lhs() else { return nil }
  return rhs(lhs)
}

and I can extract a closure which does not capture “self” at all:

class Controller {
  func provideClosure()->(Controller)->Result {
    return self\.doSomething //doesn’t capture self
  }
  func doSomething()->Result {
    //write me
  }
}

So “\” becomes:

nocapture operator \ : WhateverPrecedenceGroup

and the compiler inserts the magic of creating the “nocapture” operators, which parses nearly identically to how it works today.

Calls to UndoManager become cleaner:

class Controller {
  var color:Color {
    didSet {
      undoManager.register(withTarget:self, handler:{ (controller:Controller)->Void in
        controller.color = oldValue
      })
    }
  }
}

becomes:

class Controller {
  var color:Color {
    didSet {
      undoManager.register(withTarget:self, handler:self\.color = oldColor)
    }
  }
}

So, doing all this would:

- Give $, $0, $1, $2 consistent meanings, “the argument”.
- Solve the problem of quickly obtaining a weak / unowned closure references by creating generic 1-parameter autoclosures.
- Allow inits in optional chains.

Alternatively:

Perhaps use $0 instead inside my 1-argument auto closures, but to me it implies there could be more, and could interfere with these from an enclosing closure.

Perhaps “?” is the operator to use for creating the 1-argument closures, but to me it implies optional-related behavior

Perhaps this really is just too many “dots”, and we want to move away from the functional style, but developers are loving it.

Perhaps the UndoManager’s generic syntax is sufficient.

Perhaps I’ve missed something critical in the grammar.

Thanks your reading and consideration. Swift on!


(Daniel Duan) #20

Agree with Robert here. I'd rather be able to use it as part of operators. Currently the character set for operators and identifier head are mutually exclusive. So this proposal will remove that possibility. This deserves some discussion.

Daniel Duan

···

Sent from my iPhone

On Oct 14, 2016, at 1:33 PM, Robert Widmann via swift-evolution <swift-evolution@swift.org> wrote:

As the author of the patch that introduced this and the patch that will come out of this discussion, I have no problems one way or the other. Just bear in mind that if $ is an identifier head character then it cannot be used in operators - something I have a library with a vested interest in.

~Robert Widmann

On Oct 14, 2016, at 3:59 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier" begins now and runs through October 18. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
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