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

[Thorsten Seitz via swift-evolution]

I would prefer for $ being available as operator symbol, so -1 to the proposal.

-Thorsten

> Am 22.10.2016 um 09:22 schrieb Will Stanton via swift-evolution 
> :
> 
> On $ specifically, I found this Wikipedia article listing native operators 
> from other languages: 
> https://en.wikipedia.org/wiki/Operator_(computer_programming).
> Haskell was listed with $ as an operator (‘Anything appearing after it will 
> take precedence over anything that comes before’ per 
> http://stackoverflow.com/questions/940382/haskell-difference-between-dot-and-dollar-sign)
> 
> I’m unconvinced a great case for `$` as an operator exists, so opposed to the 
> source-breaking change, and supportive of SE-144.
> 
> 
> Jonathan,
> Thanks for the reply and Jacob, Erica, and Xiaodi as well for drafting a 
> broader proposal.
> Were you suggesting `$(0)` as a way to initialize a type named `$` or more 
> like `$0` as a literal?
> As a decimal-number/currency-type literal operator, I remain unconvinced that 
> justifies a source-breaking change for reasons discussed on list (which 
> dollar? and consistency).
> Addressing multiple problems seems like a good direction though (I like the 
> list: 
> https://github.com/jsshapiro/swift-evolution/blob/unicode-id-op/proposals/-refining-identifiers-and-operators.md#prior-discussion-threads--proposals).
> 
> A thought on the draft:
>>• Identifiers consisting of an initial '$' (U+0024 DOLLAR SIGN) followed 
>> by one or more decimal digits ['0'...'9'] are prohibited in defining 
>> occurrences. These identifiers are reserved for use by the language as 
>> anonymous closure parameter names.  
> Would it make sense/is it already the case for closure parameters to be 
> let-like constants? (I don’t know how the compiler works it, but the error 
> ‘Cannot assign to value: %something% is immutable’ makes me think no.) Can 
> closure parameters be treated as automatically generated identifiers instead 
> of a special restriction in name?
> 
> Regards,
> Will Stanton
> 
>> On Oct 21, 2016, at 10:48 PM, Jonathan S. Shapiro 
>>  wrote:
>> 
>> On Fri, Oct 14, 2016 at 9:29 PM, Will Stanton via swift-evolution 
>>  wrote:
>> I’m a bit curious about how `$` is/would be used as a prefix operator! 
>> Perhaps I’m not creative :-(
>> 
>> Well for one thing, $(0) can be understood as a value constructor for a 
>> currency object having a value zero...
> 
> ___
> 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

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

[Will Stanton via swift-evolution]

On $ specifically, I found this Wikipedia article listing native operators from 
other languages: https://en.wikipedia.org/wiki/Operator_(computer_programming).
Haskell was listed with $ as an operator (‘Anything appearing after it will 
take precedence over anything that comes before’ per 
http://stackoverflow.com/questions/940382/haskell-difference-between-dot-and-dollar-sign)

I’m unconvinced a great case for `$` as an operator exists, so opposed to the 
source-breaking change, and supportive of SE-144.


Jonathan,
Thanks for the reply and Jacob, Erica, and Xiaodi as well for drafting a 
broader proposal.
Were you suggesting `$(0)` as a way to initialize a type named `$` or more like 
`$0` as a literal?
As a decimal-number/currency-type literal operator, I remain unconvinced that 
justifies a source-breaking change for reasons discussed on list (which dollar? 
and consistency).
Addressing multiple problems seems like a good direction though (I like the 
list: 
https://github.com/jsshapiro/swift-evolution/blob/unicode-id-op/proposals/-refining-identifiers-and-operators.md#prior-discussion-threads--proposals).

A thought on the draft:
>   • Identifiers consisting of an initial '$' (U+0024 DOLLAR SIGN) 
> followed by one or more decimal digits ['0'...'9'] are prohibited in defining 
> occurrences. These identifiers are reserved for use by the language as 
> anonymous closure parameter names.  
Would it make sense/is it already the case for closure parameters to be 
let-like constants? (I don’t know how the compiler works it, but the error 
‘Cannot assign to value: %something% is immutable’ makes me think no.) Can 
closure parameters be treated as automatically generated identifiers instead of 
a special restriction in name?

Regards,
Will Stanton

> On Oct 21, 2016, at 10:48 PM, Jonathan S. Shapiro 
>  wrote:
> 
> On Fri, Oct 14, 2016 at 9:29 PM, Will Stanton via swift-evolution 
>  wrote:
> I’m a bit curious about how `$` is/would be used as a prefix operator! 
> Perhaps I’m not creative :-(
> 
> Well for one thing, $(0) can be understood as a value constructor for a 
> currency object having a value zero...

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

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

[Jonathan S. Shapiro via swift-evolution]

Now for a position:

-1 on this proposal, because '$' should be legal in *any* identifier
position.

+1 for the proposal that '$' should be legal in *any* position.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jonathan S. Shapiro via swift-evolution]

Several people here have called out implicit closure parameters as a
concern, which is actually irrelevant to adopting '$' in parameters.

It is perfectly feasible to accept '$' in parameters *generally*, and
reject identifiers of the form

$ followed by one or more decimal digits


in defining occurrences. This is completely compatible with current Swift
practice, and logically consistent with other kinds of reserved words.

I'm not taking a position pro or con here. I'm saying that we should reject
non-impacting arguments as a basis for deciding one way or the other.


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

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

[Jonathan S. Shapiro via swift-evolution]

On Wed, Oct 19, 2016 at 1:02 PM, Kevin Ballard via swift-evolution <
swift-evolution@swift.org> wrote:

> I'm actually vaguely surprised that the other currency symbols are
> considered valid identifiers, since they're not alphanumeric symbols. As
> for turning them into operators, it's a cute idea, but it doesn't work for
> any symbol that's used by multiple countries. For example, would $3.50 be
> USD, AUD, CAD, or any of the other dozens of countries that use dollars?
>

This is true, but not compelling. While using USD, AUD, CAD, and friends is
better practice for a truly internationalized code base, it does not follow
that use of $ for a more local-consumption code base should be rejected out
of hand.


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

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

[Jonathan S. Shapiro via swift-evolution]

On Tue, Oct 18, 2016 at 7:20 AM, Jay Abbott via swift-evolution <
swift-evolution@swift.org> wrote:

> It's s symbol. Here are some others:
> ! & * ( . -
>
> You wouldn't want to allow an identifier to start with any of those
> symbols, for obvious reasons.
>

That's an assertion. Can you substantiate?

Because I can think of a whole bunch of reasons for identifiers to start
with those, several languages in which they actually *do* start with those,
and significant benefit that accrues in those languages from admitting
these identifiers...
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jonathan S. Shapiro via swift-evolution]

On Fri, Oct 14, 2016 at 1:53 PM, Hooman Mehr via swift-evolution <
swift-evolution@swift.org> wrote:

> I don’t think $ will be become available to be used as an operator if we
> remove its identifier use.
>

I'm about to put out a revised proposal for operators and symbol
identifiers that addresses this.


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

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

[Brent Royal-Gordon via swift-evolution]

> On Oct 20, 2016, at 2:52 AM, Benjamin Spratling via swift-evolution 
>  wrote:
> 
> 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
> }

Pretty cryptic. What's wrong with this?

pitch = xmlNode.attributes["pitch"].map { Int($0) }
-- 
Brent Royal-Gordon
Architechies

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

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

[Benjamin Spratling via swift-evolution]

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 ?(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 

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

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 20 Oct 2016, at 07:54, Russ Bishop via swift-evolution 
>  wrote:
> 
> 
>> On Oct 17, 2016, at 11:45 PM, Rien via swift-evolution 
>>  wrote:
>> 
>> “culturally offensive” is not a logical argument.
>> A programming language should be logically consistent no matter how many 
>> cultures are offended by it.
>> If Swift is driven by SJW’s then very quickly it will cease to be an 
>> effective language.
> 
> 
> I don’t think using “SJW” as a slur is appropriate, certainly not in 
> swift-evolution. We aim to be an open and inclusive community. Cultural 
> sensitivity is one of Swift’s goals; that’s why it supports Unicode 
> identifiers… so people can use their native language if they wish. The world 
> is not the Western Latin-1 character set.

True, but sometimes restricting yourself can bring better results. A big reason 
why technical and scientific progress is advancing so fast in the modern era is 
also attributed to people being able to rely on a common lingua franca (English 
today, something else in 100 years perhaps?) and very fast communication 
amongst people of different cultural backgrounds happening at lighting speed.

People on teams resist to code guidelines for freedom of expression reasons 
too, but the values of standardisation are greater than what we achieve by 
prioritising creative expression in the form of writing all my code in kanji or 
using proper Italian accented characters or following my own code formatting 
convention... pride and fear often put people off when self imposing 
limitations for the greater good. English as programming lingua franca brings 
people together more than it suppresses valuable creative thought. 

English is obviously not my first language, but I enjoy the fact that having 
the documentation, developer forums, this kind of mailing lists, etc... all 
standardising around English as technical lingua franca is both useful, 
facilitate communication, and is totally not unprecedented (Latin used to be 
the defacto lingua franca for medicine, biology, botany, and all sorts of 
scientific and philosophical discussion... it did not kill the local languages 
and brought people together).


> None of these goals are mutually-exclusive with logical arguments; that’s a 
> false dichotomy. 
> 
> I’m not aware of any programming language that is 100% logically consistent. 
> They all make concessions to programmer culture, history, practical concerns, 
> and even opinion/whims. Python doesn’t have multi-line lambdas because Guido 
> doesn’t like them. Even Haskell has unsafePerformIO because the real world is 
> not a pure function. We talk about how beautiful or ugly syntax is all the 
> time, which is absolutely a value judgement.
> 
> 
> 
> Russ
> ___
> 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

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

[Russ Bishop via swift-evolution]

> On Oct 17, 2016, at 11:45 PM, Rien via swift-evolution 
>  wrote:
> 
> “culturally offensive” is not a logical argument.
> A programming language should be logically consistent no matter how many 
> cultures are offended by it.
> If Swift is driven by SJW’s then very quickly it will cease to be an 
> effective language.


I don’t think using “SJW” as a slur is appropriate, certainly not in 
swift-evolution. We aim to be an open and inclusive community. Cultural 
sensitivity is one of Swift’s goals; that’s why it supports Unicode 
identifiers… so people can use their native language if they wish. The world is 
not the Western Latin-1 character set.

None of these goals are mutually-exclusive with logical arguments; that’s a 
false dichotomy. 

I’m not aware of any programming language that is 100% logically consistent. 
They all make concessions to programmer culture, history, practical concerns, 
and even opinion/whims. Python doesn’t have multi-line lambdas because Guido 
doesn’t like them. Even Haskell has unsafePerformIO because the real world is 
not a pure function. We talk about how beautiful or ugly syntax is all the 
time, which is absolutely a value judgement.



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

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

[Kevin Ballard via swift-evolution]

I'm actually vaguely surprised that the other currency symbols are
considered valid identifiers, since they're not alphanumeric symbols.
As for turning them into operators, it's a cute idea, but it doesn't
work for any symbol that's used by multiple countries. For example,
would $3.50 be USD, AUD, CAD, or any of the other dozens of countries
that use dollars?

-Kevin Ballard

On Tue, Oct 18, 2016, at 09:39 AM, Nevin Brackett-Rozinsky via swift-evolution 
wrote:
> It seems natural to me that currency symbols should be operators. This
> would allow, for example, prefix and postfix operators that take a
> number and return a “Currency” instance:
>
> let inMyPocket = $20
> let lochNess = £3.50
> let twoBits = 25¢
>
> if (inMyPocket - lochNess) > twoBits { … }
>
> Of course, the unnamed closure parameter identifiers would conflict
> with that use of the dollar sign. However, I think Anton has the right
> idea. We already use the number sign for compiler magic, so it would
> make sense to call the closure parameters #0, #1, etc. In my view
> those even read better than what we have now.
>
> Nevin
>
>
> On Tue, Oct 18, 2016 at 12:19 PM, Dave Abrahams via swift-evolution
>  wrote:
>>
>> on Mon Oct 17 2016, Jean-Denis Muys > evolut...@swift.org> wrote:
>>
>>  > While I already tersely supported this proposal, following all the
>>  > negative reactions, I feel compelled to revisit my position. The
>>  > main reason is that it strikes me that most points of view so far,
>>  > including mine, were really culturally short sighted, and far too
>>  > much US-centric.
>>  >
>>  > I totally agree that '$' being use by one (or even several) piece
>>  > of code is not reason enough to change the language. But I also
>>  > think that it being used by only one piece of code is no reason to
>>  > reject the change.
>>  >
>>  > Most of us, including me, have been blinded by two things:
>>  >
>>  > 1- the use of the $ sign in other programming languages 2- the use
>>  > of the $ sign in Swift as a prefix for implicitly declared closure
>>  > parameters
>>  >
>>  > I think this second use is not Swifty at all. It clearly (to me)
>>  > would fail the litmus test "if it wasn't there, would you add it
>>  > to the language?". Of course, it has been blessed by time, and it
>>  > has *become* Swifty, by usage because it's a useful feature,
>>  > despite the choice of its syntax being so ugly (to my non-american
>>  > eyes).
>>
>> I don't think it's un-swifty by any measure.  It's not particularly
>>  beautiful, I agree, but what would make a better, extremely
>>  terse, way
>>  to refer to a posiitional parameter of a closure?  Unless we
>>  can think
>>  of something that's obviously better, then it is thoroughly
>>  swifty: a
>>  pragmatic solution for an important problem.  Unless we can think
>>  of something that's obviously better, then it certainly *is* what we
>>  would have added to the language.
>>
>>  > Similarly, I believe the use of the $ in other language should not
>>  > be a guide in the decision here, either positively, nor
>>  > negatively. We may pay some mild attention to the concern that we
>>  > should perhaps avoid some confusion. I haven't seen much of that.
>>  >
>>  > Now for the elephant in the room: '$' is a currency symbol. As
>>  > such it should be handled like any other currency symbol. Thinking
>>  > otherwise would be very culturally offensive.
>>
>> 
>>
>>  >
>>  > In conclusion, I believe this proposal must be accepted, and
>>  > actually expanded to include ¥, ¢, £, and also to make it explicit
>>  > that currency symbols can be used in variable names as first and
>>  > only character, as first of many characters, and at any position.
>>  >
>>  > This would make $0, $1, $2… legal variable names. I believe this
>>  > is OK.
>>  >
>>  > What would happen to implicitly declared closure parameters then?
>>  > Nothing. They would continue to be implicitly declared in the
>>  > context of closures that do not declare their parameters
>>  > explicitly, similarly to `self` being implicitly declared in the
>>  > context of a class. A user willing to use $0 there would be facing
>>  > a name collision, which is OK.
>>  >
>>  > Note that such a change is purely additive: no legal source code
>>  > today would fail with this change.
>>
>> That is actually a relatively un-swifty answer in some ways.
>> It means
>>  there are magic identifiers that are usable in all contexts
>>  but given
>>  special meaning in some contexts.  I think making the lexical
>>  roles of
>>  various currency symbols more consistent is a worthy goal, but
>>  I'm not
>>  sure this is the way to do it.
>>
>>  > I hope that at the very least, I opened a new perspective on this
>>  > proposal, and I hope we can find a way to be less culturally
>>  > biased.
>>
>> If there's cultural bias here, it's a bias based on programming
>> language
>>  precedent. \$[0-9] has a long history of use as a positional
>>  

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

[Kevin Ballard via swift-evolution]

On Mon, Oct 17, 2016, at 11:25 PM, Jean-Denis Muys via swift-evolution wrote:
> Now for the elephant in the room: '$' is a currency symbol. As such it
> should be handled like any other currency symbol. Thinking otherwise
> would be very culturally offensive.
>
> So can I use € as an variable name in Swift? According to Xcode
> 8.1B3, yes.
> Can I use any currency symbol as an variable name in Swift? According
> to Xcode 8.1B3, not quite, but almost all of them.
>
> [snip]
>
> Of course, this is just a data point, and Xcode8.1B3 should not be the
> arbiter here. But I believe whether Swift accepts currency symbols as
> variable names should be consistent. Either it accepts all of them, or
> it includes all of them.
>
> I see no reason to exclude them. On the contrary, it was a design
> feature of Swift to relieve use from the shackles of the ASCII
> character set.
>
> In conclusion, I believe this proposal must be accepted, and actually
> expanded to include ¥, ¢, £, and also to make it explicit that
> currency symbols can be used in variable names as first and only
> character, as first of many characters, and at any position.

Swift doesn't care about currency symbols. The Currency_Symbol general
category is not special to Swift. And the fact that $, ¥, ¢, and £ (and
don't forget about ¤, which you didn't list) aren't valid identifiers is
a consequence of how they're categorized by Unicode, not some
intentional decision by Swift. Specifically, all of the currency symbols
that are in the Basic Latin block (e.g. any currency symbol in the range
U+–U+00FF) have the Pattern_Syntax property. And the Pattern_Syntax
property is defined by Unicode (see UAX #31) as a stable set of
characters that are appropriate to use for syntax in
patterns/expressions (e.g. programming language syntax, regular
expressions, ICU number formats, etc). I don't have a good way to test
this (UnicodeChecker has no way to search for all characters with the
Pattern_Syntax property), but AFAIK all Pattern_Syntax characters are
not legal identifiers in Swift, with any character not already reserved
for use by the Swift grammar (e.g. $ being used for positional
parameters) being available for operators.

-Kevin Ballard
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Nevin Brackett-Rozinsky via swift-evolution]

It seems natural to me that currency symbols should be operators. This
would allow, for example, prefix and postfix operators that take a number
and return a “Currency” instance:

let inMyPocket = $20
let lochNess = £3.50
let twoBits = 25¢

if (inMyPocket - lochNess) > twoBits { … }

Of course, the unnamed closure parameter identifiers would conflict with
that use of the dollar sign. However, I think Anton has the right idea. We
already use the number sign for compiler magic, so it would make sense to
call the closure parameters #0, #1, etc. In my view those even read better
than what we have now.

Nevin


On Tue, Oct 18, 2016 at 12:19 PM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Mon Oct 17 2016, Jean-Denis Muys  wrote:
>
> > While I already tersely supported this proposal, following all the
> negative
> > reactions, I feel compelled to revisit my position. The main reason is
> that
> > it strikes me that most points of view so far, including mine, were
> really
> > culturally short sighted, and far too much US-centric.
> >
> > I totally agree that '$' being use by one (or even several) piece of code
> > is not reason enough to change the language. But I also think that it
> being
> > used by only one piece of code is no reason to reject the change.
> >
> > Most of us, including me, have been blinded by two things:
> >
> > 1- the use of the $ sign in other programming languages
> > 2- the use of the $ sign in Swift as a prefix for implicitly declared
> > closure parameters
> >
> > I think this second use is not Swifty at all. It clearly (to me) would
> fail
> > the litmus test "if it wasn't there, would you add it to the language?".
> Of
> > course, it has been blessed by time, and it has *become* Swifty, by usage
> > because it's a useful feature, despite the choice of its syntax being so
> > ugly (to my non-american eyes).
>
> I don't think it's un-swifty by any measure.  It's not particularly
> beautiful, I agree, but what would make a better, extremely terse, way
> to refer to a posiitional parameter of a closure?  Unless we can think
> of something that's obviously better, then it is thoroughly swifty: a
> pragmatic solution for an important problem.  Unless we can think
> of something that's obviously better, then it certainly *is* what we
> would have added to the language.
>
> > Similarly, I believe the use of the $ in other language should not be a
> > guide in the decision here, either positively, nor negatively. We may pay
> > some mild attention to the concern that we should perhaps avoid some
> > confusion. I haven't seen much of that.
> >
> > Now for the elephant in the room: '$' is a currency symbol. As such it
> > should be handled like any other currency symbol. Thinking otherwise
> would
> > be very culturally offensive.
>
> 
>
> >
> > In conclusion, I believe this proposal must be accepted, and actually
> > expanded to include ¥, ¢, £, and also to make it explicit that currency
> > symbols can be used in variable names as first and only character, as
> first
> > of many characters, and at any position.
> >
> > This would make $0, $1, $2… legal variable names. I believe this is OK.
> >
> > What would happen to implicitly declared closure parameters then?
> Nothing.
> > They would continue to be implicitly declared in the context of closures
> > that do not declare their parameters explicitly, similarly to `self`
> being
> > implicitly declared in the context of a class. A user willing to use $0
> > there would be facing a name collision, which is OK.
> >
> > Note that such a change is purely additive: no legal source code today
> > would fail with this change.
>
> That is actually a relatively un-swifty answer in some ways.  It means
> there are magic identifiers that are usable in all contexts but given
> special meaning in some contexts.  I think making the lexical roles of
> various currency symbols more consistent is a worthy goal, but I'm not
> sure this is the way to do it.
>
> > I hope that at the very least, I opened a new perspective on this
> proposal,
> > and I hope we can find a way to be less culturally biased.
>
> If there's cultural bias here, it's a bias based on programming language
> precedent. \$[0-9] has a long history of use as a positional parameter
> identifier in programming languages.  Swift very explicitly embraces
> *that* sort of “cultural bias.”  The culture of programmers matters.
>
> --
> -Dave
>
> ___
> 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

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

[Tony Allevato via swift-evolution]

On Fri, Oct 14, 2016 at 1:00 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?
>

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


>
> 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

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

[Dave Abrahams via swift-evolution]

on Mon Oct 17 2016, Jean-Denis Muys  wrote:

> While I already tersely supported this proposal, following all the negative
> reactions, I feel compelled to revisit my position. The main reason is that
> it strikes me that most points of view so far, including mine, were really
> culturally short sighted, and far too much US-centric.
>
> I totally agree that '$' being use by one (or even several) piece of code
> is not reason enough to change the language. But I also think that it being
> used by only one piece of code is no reason to reject the change.
>
> Most of us, including me, have been blinded by two things:
>
> 1- the use of the $ sign in other programming languages
> 2- the use of the $ sign in Swift as a prefix for implicitly declared
> closure parameters
>
> I think this second use is not Swifty at all. It clearly (to me) would fail
> the litmus test "if it wasn't there, would you add it to the language?". Of
> course, it has been blessed by time, and it has *become* Swifty, by usage
> because it's a useful feature, despite the choice of its syntax being so
> ugly (to my non-american eyes).

I don't think it's un-swifty by any measure.  It's not particularly
beautiful, I agree, but what would make a better, extremely terse, way
to refer to a posiitional parameter of a closure?  Unless we can think
of something that's obviously better, then it is thoroughly swifty: a
pragmatic solution for an important problem.  Unless we can think
of something that's obviously better, then it certainly *is* what we
would have added to the language.

> Similarly, I believe the use of the $ in other language should not be a
> guide in the decision here, either positively, nor negatively. We may pay
> some mild attention to the concern that we should perhaps avoid some
> confusion. I haven't seen much of that.
>
> Now for the elephant in the room: '$' is a currency symbol. As such it
> should be handled like any other currency symbol. Thinking otherwise would
> be very culturally offensive.



>
> In conclusion, I believe this proposal must be accepted, and actually
> expanded to include ¥, ¢, £, and also to make it explicit that currency
> symbols can be used in variable names as first and only character, as first
> of many characters, and at any position.
>
> This would make $0, $1, $2… legal variable names. I believe this is OK.
>
> What would happen to implicitly declared closure parameters then? Nothing.
> They would continue to be implicitly declared in the context of closures
> that do not declare their parameters explicitly, similarly to `self` being
> implicitly declared in the context of a class. A user willing to use $0
> there would be facing a name collision, which is OK.
>
> Note that such a change is purely additive: no legal source code today
> would fail with this change.

That is actually a relatively un-swifty answer in some ways.  It means
there are magic identifiers that are usable in all contexts but given
special meaning in some contexts.  I think making the lexical roles of
various currency symbols more consistent is a worthy goal, but I'm not
sure this is the way to do it.

> I hope that at the very least, I opened a new perspective on this proposal,
> and I hope we can find a way to be less culturally biased.

If there's cultural bias here, it's a bias based on programming language
precedent. \$[0-9] has a long history of use as a positional parameter
identifier in programming languages.  Swift very explicitly embraces
*that* sort of “cultural bias.”  The culture of programmers matters.

-- 
-Dave

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

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

[rintaro ishizaki via swift-evolution]

   * 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jay Abbott via swift-evolution]

>
> Now for the elephant in the room: '$' is a currency symbol. As such it
> should be handled like any other currency symbol. Thinking otherwise would
> be very culturally offensive.
>

The fact that it's a currency symbol is totally irrelevant.
It's s symbol. Here are some others:
! & * ( . -

You wouldn't want to allow an identifier to start with any of those
symbols, for obvious reasons.

Programming languages need to reserve some characters and words for special
meanings. In this case: Yes $0, $1, etc. was probably influenced from other
languages; yes $ was probably used in those languages because it was a
convenient available character in the ASCII set, and therefore easy to type
on standard US and other English keyboards (where those languages were
developed and primarily used). This is simple history/legacy, and nothing
to do with the fact it is a currency symbol or any other reason that might
cause offense to anyone.

Unfortunately I think you have misunderstood this proposal. It is to allow
$ as a single-character identifier, even though it is reserved and not
allowed as an identifier-head.

If you think $ should be allowed as the first character of any identifier
(including the single $), then that would be a different proposal which
should cover all the other effects properly.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Anton Zhilin via swift-evolution]

I'd prefer to replace $ with # in closure parameters, plus make $ equal in
rights to other currency symbols.
In C and JS, dollar sign is actually equal in rights to other currency symbols.
Swift is closer to them than to Perl, Shell, PHP, so it makes sense to
follow them here.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rien via swift-evolution]

“culturally offensive” is not a logical argument.
A programming language should be logically consistent no matter how many 
cultures are offended by it.
If Swift is driven by SJW’s then very quickly it will cease to be an effective 
language.

Having said that, I cannot think of a logical reason not to allow the $ as a 
variable name.
I also cannot think of a good reason to use a single character variable name. 
Let alone a symbol. Let even further alone a symbol that is used in many other 
languages for a specific purpose.

So while Swift may allow the $ sign for logical consistency, using it as a 
variable name would disqualify the programmer imo.

Rien.

> On 18 Oct 2016, at 08:25, Jean-Denis Muys via swift-evolution 
>  wrote:
> 
> While I already tersely supported this proposal, following all the negative 
> reactions, I feel compelled to revisit my position. The main reason is that 
> it strikes me that most points of view so far, including mine, were really 
> culturally short sighted, and far too much US-centric.
> 
> I totally agree that '$' being use by one (or even several) piece of code is 
> not reason enough to change the language. But I also think that it being used 
> by only one piece of code is no reason to reject the change.
> 
> Most of us, including me, have been blinded by two things:
> 
> 1- the use of the $ sign in other programming languages
> 2- the use of the $ sign in Swift as a prefix for implicitly declared closure 
> parameters
> 
> I think this second use is not Swifty at all. It clearly (to me) would fail 
> the litmus test "if it wasn't there, would you add it to the language?". Of 
> course, it has been blessed by time, and it has *become* Swifty, by usage 
> because it's a useful feature, despite the choice of its syntax being so ugly 
> (to my non-american eyes).
> 
> Similarly, I believe the use of the $ in other language should not be a guide 
> in the decision here, either positively, nor negatively. We may pay some mild 
> attention to the concern that we should perhaps avoid some confusion. I 
> haven't seen much of that.
> 
> Now for the elephant in the room: '$' is a currency symbol. As such it should 
> be handled like any other currency symbol. Thinking otherwise would be very 
> culturally offensive.
> 
> So can I use € as an variable name in Swift? According to Xcode 8.1B3, yes.
> Can I use any currency symbol as an variable name in Swift? According to 
> Xcode 8.1B3, not quite, but almost all of them.
> 
> According to Mac OS "Emoji and Symbols" browser, there are 37 currency 
> symbols in Unicode:
> 
> let currencyAndSymbols = "$€¥¢£₽₨₩฿₺₮₱₭₴₦৲৳૱௹﷼₹₲₪₡₫៛₵₢₸₤₳₥₠₣₰₧₯₶"
> I tried every one of them as a variable name. All were accepted, except 3: ¥, 
> ¢, £:
> 
> // let ¥ = 1 // error: expected pattern
> 
> Note the poor error message.
> 
> Here are 33 successful attempts:
> 
> let $ = 1
> let € = 1
> let ₽ = 1
> let ₨ = 1
> let ₩ = 1
> let ฿ = 1
> let ₺ = 1
> let ₮ = 1
> let ₱ = 1
> let ₭ = 1
> let ₴ = 1
> let ₦ = 1
> let ৲ = 1
> let ৳ = 1
> let ૱ = 1
> let ௹ = 1
> let ₹ = 1
> let ₲ = 1
> let ₪ = 1
> let ₡ = 1
> let ₫ = 1
> let ៛ = 1
> let ₵ = 1
> let ₢ = 1
> let ₸ = 1
> let ₤ = 1
> let ₳ = 1
> let ₥ = 1
> let ₠ = 1
> let ₣ = 1
> let ₰ = 1
> let ₧ = 1
> let ₯ = 1
> let ₶ = 1
> 
> print("₶ = \(₶)")
> print(₶+₶+₶)
> 
> And finally, there is the very weird Rial Sign: ﷼
> It is ok to use it as an variable name too (again, according to Xcode8.1B3).
> But when trying to use it, Xcode switches to right-to-left mode, which makes 
> for strange (for my occidental eyes) behaviour and display. All the following 
> is OK in Xcode:
> 
> // unusual Xcode right-to-left behavior with Rial Sign
> let ﷼ = 21
> 
> print("﷼= \(﷼)") // will print ﷼= 21
> 
> Of course, this is just a data point, and Xcode8.1B3 should not be the 
> arbiter here. But I believe whether Swift accepts currency symbols as 
> variable names should be consistent. Either it accepts all of them, or it 
> includes all of them.
> 
> I see no reason to exclude them. On the contrary, it was a design feature of 
> Swift to relieve use from the shackles of the ASCII character set.
> 
> In conclusion, I believe this proposal must be accepted, and actually 
> expanded to include ¥, ¢, £, and also to make it explicit that currency 
> symbols can be used in variable names as first and only character, as first 
> of many characters, and at any position.
> 
> This would make $0, $1, $2… legal variable names. I believe this is OK.
> 
> What would happen to implicitly declared closure parameters then? Nothing. 
> They would continue to be implicitly declared in the context of closures that 
> do not declare their parameters explicitly, similarly to `self` being 
> implicitly declared in the context of a class. A user willing to use $0 there 
> would be facing a name collision, which is OK. 
> 
> Note that such a change is purely additive: no legal source code today would 
> fail with this 

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

[Jean-Denis Muys via swift-evolution]

While I already tersely supported this proposal, following all the negative
reactions, I feel compelled to revisit my position. The main reason is that
it strikes me that most points of view so far, including mine, were really
culturally short sighted, and far too much US-centric.

I totally agree that '$' being use by one (or even several) piece of code
is not reason enough to change the language. But I also think that it being
used by only one piece of code is no reason to reject the change.

Most of us, including me, have been blinded by two things:

1- the use of the $ sign in other programming languages
2- the use of the $ sign in Swift as a prefix for implicitly declared
closure parameters

I think this second use is not Swifty at all. It clearly (to me) would fail
the litmus test "if it wasn't there, would you add it to the language?". Of
course, it has been blessed by time, and it has *become* Swifty, by usage
because it's a useful feature, despite the choice of its syntax being so
ugly (to my non-american eyes).

Similarly, I believe the use of the $ in other language should not be a
guide in the decision here, either positively, nor negatively. We may pay
some mild attention to the concern that we should perhaps avoid some
confusion. I haven't seen much of that.

Now for the elephant in the room: '$' is a currency symbol. As such it
should be handled like any other currency symbol. Thinking otherwise would
be very culturally offensive.

So can I use € as an variable name in Swift? According to Xcode 8.1B3, yes.
Can I use any currency symbol as an variable name in Swift? According to
Xcode 8.1B3, not quite, but almost all of them.

According to Mac OS "Emoji and Symbols" browser, there are 37 currency
symbols in Unicode:

let currencyAndSymbols = "$€¥¢£₽₨₩฿₺₮₱₭₴₦৲৳૱௹﷼₹₲₪₡₫៛₵₢₸₤₳₥₠₣₰₧₯₶"
I tried every one of them as a variable name. All were accepted, except 3:
¥, ¢, £:

// let ¥ = 1 // error: expected pattern

Note the poor error message.

Here are 33 successful attempts:

let $ = 1

let € = 1

let ₽ = 1

let ₨ = 1

let ₩ = 1

let ฿ = 1

let ₺ = 1

let ₮ = 1

let ₱ = 1

let ₭ = 1

let ₴ = 1

let ₦ = 1

let ৲ = 1

let ৳ = 1

let ૱ = 1

let ௹ = 1

let ₹ = 1

let ₲ = 1

let ₪ = 1

let ₡ = 1

let ₫ = 1

let ៛ = 1

let ₵ = 1

let ₢ = 1

let ₸ = 1

let ₤ = 1

let ₳ = 1

let ₥ = 1

let ₠ = 1

let ₣ = 1

let ₰ = 1

let ₧ = 1

let ₯ = 1

let ₶ = 1

print("₶ = \(₶)")

print(₶+₶+₶)

And finally, there is the very weird Rial Sign: ﷼
It is ok to use it as an variable name too (again, according to Xcode8.1B3).
But when trying to use it, Xcode switches to right-to-left mode, which
makes for strange (for my occidental eyes) behaviour and display. All the
following is OK in Xcode:

// unusual Xcode right-to-left behavior with Rial Sign

let ﷼ = 21


print("﷼= \(﷼)") // will print ﷼= 21

Of course, this is just a data point, and Xcode8.1B3 should not be the
arbiter here. But I believe whether Swift accepts currency symbols as
variable names should be consistent. Either it accepts all of them, or it
includes all of them.

I see no reason to exclude them. On the contrary, it was a design feature
of Swift to relieve use from the shackles of the ASCII character set.

In conclusion, I believe this proposal must be accepted, and actually
expanded to include ¥, ¢, £, and also to make it explicit that currency
symbols can be used in variable names as first and only character, as first
of many characters, and at any position.

This would make $0, $1, $2… legal variable names. I believe this is OK.

What would happen to implicitly declared closure parameters then? Nothing.
They would continue to be implicitly declared in the context of closures
that do not declare their parameters explicitly, similarly to `self` being
implicitly declared in the context of a class. A user willing to use $0
there would be facing a name collision, which is OK.

Note that such a change is purely additive: no legal source code today
would fail with this change.

I hope that at the very least, I opened a new perspective on this proposal,
and I hope we can find a way to be less culturally biased.

Jean-Denis

* What is your evaluation of the proposal?

+1. However, it should be expanded to include all Unicode currency symbols.

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

Very much so, because it reveals a significant inconsistency in the way the
language handles characters for identifiers.

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

Very much so, considering the language made a point to support unicode
characters in identifiers, and '$' should behave consistently with the
other Unicode currency symbols.

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

In the specific case, this is irrelevant. We are in territory only treaded
by Swift

* How much effort did you put 

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

[Jay Abbott via swift-evolution]

> * What is your evaluation of the proposal?

I am against it.

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

No - if this change were made it would be a regression. The rationale for
removing it in the first place was and remains valid.

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

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.

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

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

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.

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

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.


On Sun, 16 Oct 2016 at 17:31 Jacob Bandes-Storch via swift-evolution <
swift-evolution@swift.org> wrote:

> Proposal link:
>
>
> 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?
>
>
> -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  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 ;-)
>
>
>
> * 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.
>
> ___
> 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

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

[Jacob Bandes-Storch via swift-evolution]

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  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
;-)



> * 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.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Russ Bishop via swift-evolution]

> On Oct 14, 2016, at 12:59 PM, 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?
> 

-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


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

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

[Jonathan Hull via swift-evolution]

>   * What is your evaluation of the proposal?
-1.  I would much rather see it either as an operator, or more likely as some 
other special syntax/meaning in Swift.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
No. Providing backwards compatibility with a single library that used an 
undocumented feature is not a significant enough reason.

>   * Does this proposal fit well with the feel and direction of Swift?
No.
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

I read the proposal and previous reviews.

Thanks,
Jon___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Georgios Moschovitis via swift-evolution]

> * 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

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

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

[Haravikk via swift-evolution]

> On 14 Oct 2016, at 20:59, Chris Lattner via swift-evolution 
>  wrote:
> 
>   * 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.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Will Stanton via swift-evolution]

I’m a bit curious about how `$` is/would be used as a prefix operator! Perhaps 
I’m not creative :-(

Regards,
Will Stanton

> On Oct 14, 2016, at 6:42 PM, Alex Martini via swift-evolution 
>  wrote:
> 
>> On Oct 14, 2016, at 1:53 PM, Hooman Mehr via swift-evolution 
>>  wrote:
>> 
>>> On Oct 14, 2016, at 1:49 PM, Daniel Duan via swift-evolution 
>>>  wrote:
>>> 
>>> 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
>> 
>> I don’t think $ will be become available to be used as an operator if we 
>> remove its identifier use. 
> 
> If $ is an operator, then "$2" looks like the custom unary prefix operator 
> "$" applied to "2".  That's a problem; it needs to be parsed as the 
> identifier "$2" instead.
> 
> We could prevent "$" from being allowed a prefix operator.  There is 
> precedent for the language reserving operators that would otherwise be 
> allowed, such as postfix "?" and postfix "!".

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

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

[Daniel Müllenborn via swift-evolution]

* 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.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charles Srstka via swift-evolution]

> On Oct 14, 2016, at 2:59 PM, 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

> * 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

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

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

[Daniel Duan via swift-evolution]

> On Oct 14, 2016, at 3:42 PM, Alex Martini via swift-evolution 
>  wrote:
> 
>> On Oct 14, 2016, at 1:53 PM, Hooman Mehr via swift-evolution 
>> > wrote:
>> 
>>> On Oct 14, 2016, at 1:49 PM, Daniel Duan via swift-evolution 
>>> > wrote:
>>> 
>>> 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
>> 
> 
>> I don’t think $ will be become available to be used as an operator if we 
>> remove its identifier use. 
> 
> 
> If $ is an operator, then "$2" looks like the custom unary prefix operator 
> "$" applied to "2".  That's a problem; it needs to be parsed as the 
> identifier "$2" instead.
> 
> We could prevent "$" from being allowed a prefix operator.  There is 
> precedent for the language reserving operators that would otherwise be 
> allowed, such as postfix "?" and postfix "!".
> 

Yes, we might have to special case the parser for this. I imagine some flag 
such as “isParsingClosureWithoutExplicitParameter”. At least it’s not 
impossible 

> — Alex
> ___
> 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

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

[Richard Wei via swift-evolution]

> * 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 
>  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

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

[Alex Martini via swift-evolution]

> On Oct 14, 2016, at 1:53 PM, Hooman Mehr via swift-evolution 
>  wrote:
> 
>> On Oct 14, 2016, at 1:49 PM, Daniel Duan via swift-evolution 
>> > wrote:
>> 
>> 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
> 

> I don’t think $ will be become available to be used as an operator if we 
> remove its identifier use. 


If $ is an operator, then "$2" looks like the custom unary prefix operator "$" 
applied to "2".  That's a problem; it needs to be parsed as the identifier "$2" 
instead.

We could prevent "$" from being allowed a prefix operator.  There is precedent 
for the language reserving operators that would otherwise be allowed, such as 
postfix "?" and postfix "!".

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

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

[Matthew Johnson via swift-evolution]

>   * 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


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

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

[Hooman Mehr via swift-evolution]

I don’t think $ will be become available to be used as an operator if we remove 
its identifier use. 

> On Oct 14, 2016, at 1:49 PM, Daniel Duan via swift-evolution 
>  wrote:
> 
> 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 
> > 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 
>>> > 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 
>> 
> ___
> 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

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

[Daniel Duan via swift-evolution]

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 
>  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 
>>  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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Felipe Cypriano via swift-evolution]

-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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Robert Widmann via swift-evolution]

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 
>  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

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

[Chris Lattner via swift-evolution]

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