<div dir="ltr"><div>> * What is your evaluation of the proposal?<br><br></div>I am against it.<br><div><br class="gmail_msg">
> * Is the problem being addressed significant enough to warrant a change to Swift?<br><br></div><div>No - if this change were made it would be a regression. The rationale for removing it in the first place was and remains valid.<br></div><div><br class="gmail_msg">
> * Does this proposal fit well with the feel and direction of Swift?<br><br></div><div>No, it goes in the opposite direction. $ is not valid as the first character of a user-defined identifier and therefore should not be a valid identifier by itself.<br><br></div><div>Side-note: Personally I think $ as the first character of an identifier should be reserved for shorthand ways to do other things, in line with how it is currently used in Swift.<br></div><div>If used consistently, programmers will know they are seeing a language shortcut. Allowing $ as an identifier would break some of the natural intuition a programmer is able to use when learning and reading Swift code.<br></div><div></div><div><br class="gmail_msg">
> * If you have used other languages or libraries with a
similar feature, how do you feel that this proposal compares to those?<br><br></div><div>The proposal seems purely for the benefit of the Dollar library, which could work just as well with any other identifier. Code using the dollar library is reminiscent of some other languages and programming styles. This isn't really a comment about the proposal itself, more the motivation behind it.<br></div><div><br class="gmail_msg">
> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br><br></div><div>I read the proposal and was perplexed by it, so I looked into the Dollar library to try and understand the motivation behind the proposal. It is a clever library with some nice features and tricks, but in many ways it seems to be designed to enable programmers to write non-Swifty code in Swift. I can understand the frustration of the author and users of the library, but its functionality could be provided in a Swifty way using extensions and generics, and I think if those users embraced this they would ultimately appreciate the change. If not then they might as well stick to another language.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, 16 Oct 2016 at 17:31 Jacob Bandes-Storch via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Proposal link: </div><br style="font-size:12.8px" class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md" rel="noreferrer" style="font-size:12.8px" class="gmail_msg" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md</a></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> * What is your evaluation of the proposal?<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">-1.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The proposal does not actually provide motivation for keeping $ beyond "the Dollar library already uses it".</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">$.at → convenience subscript(Index...) for Collection</div><div class="gmail_msg">$.chunk → convenience function for Sequence</div><div class="gmail_msg">$.compact → flatMap{$0}</div><div class="gmail_msg">$.contains → already exists as Sequence.contains</div><div class="gmail_msg">$.cycle → convenience function for Collection</div><div class="gmail_msg">$.difference → convenience function on Collection, or just use Set operations, or filter</div><div class="gmail_msg">$.each → exists as Sequence.forEach</div>$.every → extension on Sequence<div class="gmail_msg">$.factorial → convenience method or postfix operator for Integer</div><div class="gmail_msg">$.fetch → convenience function on Collection</div><div class="gmail_msg">and so on.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">It looks like the author's <a href="https://github.com/ankurp/Cent" class="gmail_msg" target="_blank">Cent</a> library is already taking this approach.</div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* Is the problem being addressed significant enough to warrant a change to Swift?<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Yes, but the change has already been made: removing $ as a valid identifier ;-)</div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* Does this proposal fit well with the feel and direction of Swift?<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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.)</div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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.</div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div>
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>