Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Just to play devil’s advocate (since I am honestly ok with the less draconian form of the proposal now), wouldn’t it be possible to declare the relevant unicode characters in the module’s plist (or similar file)? I know it isn’t the most elegant solution, but it does move the bar on using

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

True, but that doesn’t mean we have to resign ourselves the lowest common denominator. We need a way to operate with older systems, but we also want to embrace what has been made possible now. Within a few years, it is quite likely that this technology will be common both across Apple’s

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 25, 2016, at 3:19 AM, Xiaodi Wu wrote: > > Unfortunately, Joe is correct on this point. As I stated earlier in the > thread, there are a series of characters that can be either text or emoji in > presentation, where the default presentation differs depending on

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

And there’s our confirmation of hardware emoji keyboard. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

I'm not aware of any Unicode stipulations on rendering of unassigned code points. In any case, Swift _n_ doesn't need to be designed around specific platforms that exist in 2016, but it'd be perfectly sensible to say that Swift 4 should restrict valid identifiers to those characters that are

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 27, 2016, at 11:46 AM, Jonathan Hull via swift-evolution > wrote: > > It looks like the issue of typing unicode symbols was solved much sooner than > any of us were predicting… > > Thanks, > Jon Swift as a language extends beyond Apple's platform and

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

+1 -Thorsten > Am 20.10.2016 um 02:32 schrieb Nevin Brackett-Rozinsky via swift-evolution > : > > I strongly oppose the proposed mass-removal of operator characters. It would > be a major loss to the Swift language if that were to occur even temporarily. > > The

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

It looks like the issue of typing unicode symbols was solved much sooner than any of us were predicting… Thanks, Jon ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Sent from my iPhone > On Oct 25, 2016, at 10:24, Joe Groff via swift-evolution > wrote: > >> Ok, but to clarify the requirement, *every* file would have to declare the >> operators it is using at the top of the file. It isn’t enough for them to >> be declared in

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 24, 2016, at 22:33, Chris Lattner via swift-evolution > wrote: > would it be possible to carve off some obvious blocks of emoji support as > identifiers (e.g. not symbols, flags, or anything else complicated), and > carve off the most obvious blocks of the

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 25, 2016, at 3:08 PM, Anton Zhilin via swift-evolution > wrote: > > Why can't we just remove distinction between operator and identifier symbols? > I'd be fine with the following: This has been discussed in prior threads: it is core to the behavior of the

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> Am 26.10.2016 um 00:08 schrieb Anton Zhilin via swift-evolution > : > > Why can't we just remove distinction between operator and identifier symbols? > I'd be fine with the following: > > ```swift > infix operator map > infix func map(lhs: [Int], rhs: (Int) ->

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Why can't we just remove distinction between operator and identifier symbols? I'd be fine with the following: ```swift infix operator map infix func map(lhs: [Int], rhs: (Int) -> Int) { ... } [1,2,3] map {$0*2} ``` No explicit imports required, plus we can create nice DSLs. Of course, it's an

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

I’m also -1 on disallowing emojis as identifiers. As it was stated may times before, emojis are an important part of modern communication, especially between young people and kids. I understand the complexity of keeping them around, especially if they are not well-defined by Unicode and if

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 24, 2016, at 10:40 PM, Russ Bishop wrote: > >> >> On Oct 24, 2016, at 9:43 AM, Joe Groff via swift-evolution >> > wrote: >> >> >>> On Oct 23, 2016, at 9:41 PM, Chris Lattner via swift-evolution >>>

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 24, 2016, at 10:15 PM, Chris Lattner wrote: > >> >> On Oct 24, 2016, at 9:40 AM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Oct 22, 2016, at 5:53 PM, Jonathan S. Shapiro >>> wrote: >>> >>> I

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Unfortunately, Joe is correct on this point. As I stated earlier in the thread, there are a series of characters that can be either text or emoji in presentation, where the default presentation differs depending on platform, technology, use case, or context. This is also not a bug, but explicitly

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 24, 2016, at 9:43 AM, Joe Groff via swift-evolution > wrote: > > >> On Oct 23, 2016, at 9:41 PM, Chris Lattner via swift-evolution >> > wrote: >> >> >>> On Oct 18, 2016, at 11:34 PM, Jacob

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 21, 2016, at 9:38 PM, Jonathan S. Shapiro via swift-evolution > wrote: > > Well, it seems that I jumped the gun and sent my document link to > swift-evolution by mistake. Since I can't take it back, it might be good to > say what it's about. Because of my

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 24, 2016, at 9:40 AM, Joe Groff via swift-evolution > wrote: > > >> On Oct 22, 2016, at 5:53 PM, Jonathan S. Shapiro >> > wrote: >> >> I missed this earlier posting from Joe Groff, who

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 20, 2016, at 5:03 PM, Jonathan S. Shapiro via swift-evolution > wrote: > > On Thu, Oct 20, 2016 at 12:25 PM, Jonathan Hull via swift-evolution > > wrote: > Would it be possible to do the

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 20, 2016, at 7:03 AM, Jonathan S. Shapiro via swift-evolution > wrote: > > On Thu, Oct 20, 2016 at 12:12 AM, Austin Zheng via swift-evolution > > wrote: > Is there a compromise we can come up

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 19, 2016, at 1:46 PM, Brent Royal-Gordon via swift-evolution > wrote: > > I was in the middle of writing about my opposition to the original proposal > when I went to bed last night, and was going to advocate something like this: > >> Given the current

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 22, 2016, at 5:53 PM, Jonathan S. Shapiro > wrote: > > I missed this earlier posting from Joe Groff, who wrote: > > In the discussion about operators, I wonder whether it makes sense to > formally separate "identifier" and "operator" characters at all.

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 23, 2016, at 9:41 PM, Chris Lattner via swift-evolution > wrote: > > >> On Oct 18, 2016, at 11:34 PM, Jacob Bandes-Storch via swift-evolution >> > wrote: >> >> Dear Swift-Evolution community, >>

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 18, 2016, at 11:34 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > Dear Swift-Evolution community, > > A few of us have been preparing a proposal to refine the definitions of > identifiers & operators. This includes some changes to the permitted

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Jonathan, that’s a really nice proposal! :-) You also already achieved some points from your „future directions“ ;-) — Martin ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Re: ### Conventional Identifiers `conventional-ident-head → [:Emoji:]` will include the keycap base characters ('#', '*', ASCII digits).

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 22, 2016, at 8:53 PM, Jonathan S. Shapiro > wrote: > > I missed this earlier posting from Joe Groff, who wrote: > > In the discussion about operators, I wonder whether it makes sense to > formally separate "identifier" and "operator" characters at all.

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

I missed this earlier posting from Joe Groff, who wrote: In the discussion about operators, I wonder whether it makes sense to > formally separate "identifier" and "operator" characters at all. ... The consequence if we do not formally separate the operators (verbs) from the identifiers (nouns)

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

I’m a -1 on the original proposal. I can see the logic in doing things that way, but it’s really unclear to me why we need to act *now*. In fact it seems like waiting might be a better option, given the things mentioned upthread about revisions to the Unicode standard. Also, I think the

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

That, I think, is where we're headed. Take a look at Jonathan Shapiro's latest draft and see what you think :) On Sat, Oct 22, 2016 at 17:46 Matt Whiteside via swift-evolution < swift-evolution@swift.org> wrote: > > On Oct 19, 2016, at 19:07, Jonathan Hull via swift-evolution < >

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 19, 2016, at 19:07, Jonathan Hull via swift-evolution > wrote: > There are a bunch of symbols in unicode which are hard to tell apart, and > those are bad for recognition, and we should deal with that, but this > proposal is throwing the baby out with the

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

It’s worth pointing out that the proposal to add ‘$’ to identifiers is still under active review and have generated much controversy. I wouldn’t put much weight in “backward compatibility” for that proposal. > On Oct 21, 2016, at 9:38 PM, Jonathan S. Shapiro via swift-evolution >

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 20, 2016, at 9:37 AM, Jonathan S. Shapiro > wrote: > > On Thu, Oct 20, 2016 at 7:30 AM, David Sweeris > wrote: > Sent from my iPhone > > On Oct 20, 2016, at 09:03, Jonathan S. Shapiro via

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

On Sat, Oct 22, 2016 at 1:37 AM, Nevin Brackett-Rozinsky via swift-evolution wrote: > I just read through your new proposal, and I have to say it is extremely > well-written. There is a vast quantity of information presented quite > clearly, and it gives me a lot to

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

I just read through your new proposal, and I have to say it is extremely well-written. There is a vast quantity of information presented quite clearly, and it gives me a lot to think about. On Fri, Oct 21, 2016 at 5:38 PM, Jonathan S. Shapiro < jonathan.s.shap...@gmail.com> wrote: > On Fri, Oct

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

All: Xiaodi has pointed out that the existing Unicode emoji set pulls in a host of stuff we don't want. My bad for failing to adequately understand what that file represented. We can either pull in selected blocks with appropriate sanity filters or possibly consider adopting the Unicode

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

On Fri, Oct 21, 2016 at 9:26 PM, Xiaodi Wu wrote: > You kinda sent that to swift-evolution :P > Another painful reminder of why "oops" is a four-letter word... Sorry! Jonathan ___ swift-evolution mailing list

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Well, it seems that I jumped the gun and sent my document link to swift-evolution by mistake. Since I can't take it back, it might be good to say what it's about. Because of my mistake, this version has *not* had any review by the rest of the author group, which probably would have improved it a

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

On Fri, Oct 21, 2016 at 4:32 PM, Jonathan S. Shapiro < jonathan.s.shap...@gmail.com> wrote: > On Fri, Oct 21, 2016 at 1:10 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > >> A few other thoughts: >> >> * One of our (or at least my) overarching goals for this proposal is

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

On Fri, Oct 21, 2016 at 4:32 PM, Jonathan S. Shapiro < jonathan.s.shap...@gmail.com> wrote: > On Fri, Oct 21, 2016 at 1:10 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > >> A few other thoughts: >> >> * One of our (or at least my) overarching goals for this proposal is

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

On Fri, Oct 21, 2016 at 1:51 PM, Martin Waitz via swift-evolution < swift-evolution@swift.org> wrote: > With the current difficulty to come up with an agreed set of identifies > vs. operators, maybe we should really try to sidestep this issue entirely > and study Jonathan Shapiro’s idea of using

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

On Fri, Oct 21, 2016 at 1:54 PM, Nevin Brackett-Rozinsky via swift-evolution wrote: > I think it is plainly evident that the well-defined criteria you would > like to use *have not yet been defined* by Unicode. That is a large part of > why I recommend that we postpone

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

On Fri, Oct 21, 2016 at 1:10 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > A few other thoughts: > > * One of our (or at least my) overarching goals for this proposal is to > refine identifier and operator sets by moving away from an ad-hoc > character-by-character

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

I think it is plainly evident that the well-defined criteria you would like to use *have not yet been defined* by Unicode. That is a large part of why I recommend that we postpone a major overhaul of our operator characters. Furthermore, just like during the Great Renaming—when we used some

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

With the current difficulty to come up with an agreed set of identifies vs. operators, maybe we should really try to sidestep this issue entirely and study Jonathan Shapiro’s idea of using identifiers as operators. — Martin > Am 21.10.2016 um 22:10 schrieb Xiaodi Wu via swift-evolution >

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

A few other thoughts: * One of our (or at least my) overarching goals for this proposal is to refine identifier and operator sets by moving away from an ad-hoc character-by-character approach to a systematic treatment that relies on well-defined criteria to select blocks of characters for

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

I disagree pretty strongly with this approach. Firstly because as you've pointed out, changes to the operator characters will have effects on valid operator character sets, secondly because a major question about operators is whether it is feasible or no to manually exclude empty set and infinity

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

I think it is important that we as a community discuss the non-operator portion of this proposal. And, given the strong opinions about operators that have been expressed, I think it is unlikely we will do so while major operator changes are on the table. Thus I would suggest that either the

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On 21 Oct 2016, at 13:42, Benjamin Spratling wrote: > > Brackets and symbols are definitely operators. Different brackets are used > to represent various quantum mechanical forms and operations. The brackets are mostly "bracket pieces": [:Math_Symbol:] -

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Brackets and symbols are definitely operators. Different brackets are used to represent various quantum mechanical forms and operations. Arrows are also useful as operators, including but not restricted to chemical reactions. -Ben Sent from my iPhone. > On Oct 21, 2016, at 7:20 AM, Ben

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On 20 Oct 2016, at 15:29, Jonathan S. Shapiro wrote: > > Quick poll as a sanity check on a possible alternative for operators: > > If we admitted [:Sm:] and [:So:] and the traditional ASCII operator > characters, would that cover the things that people currently feel passionate > about?

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

On Thu, Oct 20, 2016 at 12:25 PM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > Would it be possible to do the following: > > • Have 1 group which are always used as identifiers. This would probably > be the identifiers from this proposal. > > • Have a 2nd group which

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

On Thu, Oct 20, 2016 at 9:29 AM, Jonathan S. Shapiro via swift-evolution < swift-evolution@swift.org> wrote: > Quick poll as a sanity check on a possible alternative for operators: > > If we admitted [:Sm:] and [:So:] and the traditional ASCII operator > characters, would that cover the things

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

On Thu, Oct 20, 2016 at 8:22 AM, Alex Blewitt wrote: > The "Symbol, Other" category contains "Sign of the Horns" 落 which was > one of the problems with the identifier/operator that kicked off these > discussions. > Actually not. In the interests of sanity I didn't give the

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

The "Symbol, Other" category contains "Sign of the Horns" 落 which was one of the problems with the identifier/operator that kicked off these discussions. http://www.fileformat.info/info/unicode/char/1f918/index.htm So it would break some existing cases, e.g.: 1> let \U+1F913 = "nerd face" 邏:

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

On Thu, Oct 20, 2016 at 8:18 AM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > > I fully agree. It’s hella presumptuous to decide that I’m not allowed to > express whimsy, frustration, humor, or any other emotions in my code. Or to > tell an 8 year old using Playgrounds on

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

On Thu, Oct 20, 2016 at 8:08 AM, Erica Sadun wrote: > I really liked Jonathan's suggestion that removed the distinction between > operators and identifiers entirely. You could mark a one-argument function > as postfix or prefix, and a two-argument function as infix and use

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 20, 2016, at 12:37 AM, Russ Bishop via swift-evolution > wrote: > > >> On Oct 19, 2016, at 1:46 PM, Brent Royal-Gordon via swift-evolution >> > wrote: >> >> I was in the middle of writing about

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Operators, Nouns, and Verbs There's an issue that I think it's worth bringing it out into the open for everyone to see so that we all know it is present. Solutions are possible, but they go beyond the scope of the identifier proposal. Here's the brief statement of the problem: 1. Operators

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 19, 2016, at 11:17 PM, Jonathan S. Shapiro via swift-evolution > wrote: > > On Wed, Oct 19, 2016 at 1:31 PM, David Waite via swift-evolution > > wrote: > The problem is that this set does not just

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 20, 2016, at 9:29 AM, Jonathan S. Shapiro via swift-evolution > wrote: > > Quick poll as a sanity check on a possible alternative for operators: > > If we admitted [:Sm:] and [:So:] and the traditional ASCII operator > characters, would that cover the

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

On Thu, Oct 20, 2016 at 7:30 AM, David Sweeris wrote: > Sent from my iPhone > > On Oct 20, 2016, at 09:03, Jonathan S. Shapiro via swift-evolution < > swift-evolution@swift.org> wrote: > > On Thu, Oct 20, 2016 at 12:12 AM, Austin Zheng via swift-evolution < >

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Sent from my iPhone > On Oct 20, 2016, at 09:03, Jonathan S. Shapiro via swift-evolution > wrote: > >> On Thu, Oct 20, 2016 at 12:12 AM, Austin Zheng via swift-evolution >> wrote: >> >> Freeze the set of allowed emoji to whatever the

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Quick poll as a sanity check on a possible alternative for operators: If we admitted [:Sm:] and [:So:] and the traditional ASCII operator characters, would that cover the things that people currently feel passionate about? That would almost certainly be compliant with UAX31 once it settles, and I

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Said differently: A monkey with a tool is still a monkey. I.e. Swift cannot force somebody to become a good programmer no matter what rules it imposes. As far as limiting personal freedoms goes: everybody (kid’s included) should be able to use whatever pleases them - within the possibilities of

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

I'm sympathetic to the arguments you raise here. However, they were brought up during the SetAlgebra API discussion and rejected in favor of the current API. Now is not the time to re-litigate that thread. The point I'm making is that it's all right if Swift's operators happen to support the

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On 19 Oct 2016, at 19:00,Xiaodi Wu wrote: > > However, it's specifically the set algebra operators that I have the > greatest objection to cherrypicking: > > * Each of these operators has a specific meaning; it is an anti-goal to > support repurposing the union operator for any other purpose

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On 20 Oct 2016, at 08:34,Nevin Brackett-Rozinsky wrote: > > So I am strongly—adamantly—opposed to the operator-eviscerating portion of > this proposal. > > We should make Braille characters, Hangzhou numerals, the empty set and the > infinity sign into identifiers. All other operators should

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Is there a compromise we can come up with, maybe? Allow emoji in identifiers, but freeze the set of allowed emoji to whatever the current version of the Unicode spec defines with the intention that 'automatic expansion' of the allowed character set to accommodate future emoji is a non-goal?

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Point well taken, but FWIW, there is a large difference between *you* expressing whimsy and committing the language to an open-ended series of continuous revisions for the sole purpose of enabling one particular form of whimsy. It's rather an overstatement to say that we are proposing to "squash

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> Le 20 oct. 2016 à 02:11, Xiaodi Wu via swift-evolution > a écrit : > > I actually take the opposite view of emoji, and I was convinced of this by > arguments from some of the other authors (though they may not come to the > same conclusions as I do): > > The

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 19, 2016, at 1:46 PM, Brent Royal-Gordon via swift-evolution > wrote: > > I was in the middle of writing about my opposition to the original proposal > when I went to bed last night, and was going to advocate something like this: > >> Given the current

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Strong -1 from me as currently written. There is no reason to remove Emoji from identifiers, nor to restrict operators to ASCII only (especially since the corresponding UAX spec is still under construction). Emoji are just as much a part of modern communication as the Latin alphabet. Swift

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

If someone wants to write their variable names in Spanish or Japanese, they should be able to. That is one of the main reasons for including unicode. (Note it might make it more difficult for me to read, but it makes it easier for them and their team). If a group of mathematicians find it

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

On Wed, Oct 19, 2016 at 10:26 PM, Nevin Brackett-Rozinsky via swift-evolution wrote: > Thinking about it further, I am not convinced we need to make *any* change > to the set of operator characters at this time. It’s not like people are > clamoring to have Braille

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Thinking about it further, I am not convinced we need to make *any* change to the set of operator characters at this time. It’s not like people are clamoring to have Braille variable names after all. And as much as I’d like to see the upside-down ampersand (⅋) as an operator, that too can wait. I

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

An EXTREME -1 from me as well. The restrictions on operators is FAR too severe. At the very least, I need the upside-down question mark and exclamation points ¿ ¡, as well as the ≤,≥,≠ operators. I mean, you are getting rid of the division sign ÷. How could that ever be controversial as an

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

I strongly oppose the proposed mass-removal of operator characters. It would be a major loss to the Swift language if that were to occur even temporarily. The long-term goal is for Swift to adopt the official Unicode guidance for operator characters, which is still under development. Therefore I

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

I actually take the opposite view of emoji, and I was convinced of this by arguments from some of the other authors (though they may not come to the same conclusions as I do): The real and very weighty reason Swift should support Unicode identifiers is that naming things is hard, and it is

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> > > IMO, the best argument against using unicode symbols for operators defined by > mathematics is that they are currently difficult to type. > > And there is no realistic hope of that changing. This issue is so compelling > that C and C++ introduced standardized text-ascii alternatives for

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

I was in the middle of writing about my opposition to the original proposal when I went to bed last night, and was going to advocate something like this: > Given the current state of the discussion over in Unicode land, I think it > would probably be safe from a compatibility standpoint to

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 19, 2016, at 12:29 PM, Jonathan S. Shapiro via swift-evolution > wrote: > > On Wed, Oct 19, 2016 at 6:41 AM, Matthew Johnson via swift-evolution > > wrote: > IMO, the best argument against using

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 18, 2016, at 11:34 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > However, Swift's current identifier and operator character sets do not > conform to any Unicode standards, nor have they been rationalized in the > language or compiler

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

The problem is that this set does not just contain mathematical operators, but includes among other examples \u2205 (Empty Set) and \u221E (infinity). -DW > On Oct 19, 2016, at 1:49 PM, Paul Cantrell via swift-evolution > wrote: > At the very least, Swift ought to

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 19, 2016, at 12:21 PM, Rob Mayoff via swift-evolution > wrote: > > On Wed, Oct 19, 2016 at 10:47 AM, plx via swift-evolution > > wrote: > In any case, I’d specifically hate to lose these: > > -

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 19, 2016, at 12:27 PM, Erica Sadun wrote: > > >> On Oct 19, 2016, at 7:41 AM, Matthew Johnson via swift-evolution >> wrote: >> >> I very much support the proposal to rationalize our handling of identifier >> characters. >> >> I

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

On Wed, Oct 19, 2016 at 6:41 AM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > If I’m reading the proposal and discussion properly, the group has not > able to reach consensus on the right criteria for operator symbols, but is > hopeful that will be possible after the

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 19, 2016, at 7:41 AM, Matthew Johnson via swift-evolution > wrote: > > I very much support the proposal to rationalize our handling of identifier > characters. > > I also support doing something similar for operator symbols. However, I > agree feedback

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

On Wed, Oct 19, 2016 at 10:21 AM, Rob Mayoff via swift-evolution < swift-evolution@swift.org> wrote: > On Wed, Oct 19, 2016 at 10:47 AM, plx via swift-evolution < > swift-evolution@swift.org> wrote: > >> In any case, I’d specifically hate to lose these: >> >> - approximate equality: ≈ >> - set

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

On Wed, Oct 19, 2016 at 10:12 AM, Alex Martini via swift-evolution < swift-evolution@swift.org> wrote: > > > > > I think there's a mismatch between the English and

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

On Wed, Oct 19, 2016 at 10:47 AM, plx via swift-evolution < swift-evolution@swift.org> wrote: > In any case, I’d specifically hate to lose these: > > - approximate equality: ≈ > - set operations: ∩, ∪ > - set relations: ⊂, ⊃, ⊄, ⊅, ⊆, ⊇, ⊈, ⊉, ⊊, ⊋ > - set membership: ∌, ∋, ∈, ∉ > - logical

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> Dots in operators > > The current requirements for dots in operator names are: > > If an operator doesn’t begin with a dot, it can’t contain a dot elsewhere. > This proposal changes the rule to: > > Dots may only appear in operators in runs of two or more. > Under the revised rule, ..< and

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

On Wed, Oct 19, 2016 at 4:09 AM, Benjamin Spratling via swift-evolution < swift-evolution@swift.org> wrote: > Some extremely short-sighted points about deleting my formal operators > that are widely recognized as operators, and that I’ve spent months adding > into my code. Frankly, I just

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Personally, a *very* limited cherrypicking might be OK, on the understanding that it must be done with very stringent inclusion criteria. However, it's specifically the set algebra operators that I have the greatest objection to cherrypicking: * Each of these operators has a specific meaning; it

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

I think this is a promising direction. Getting us in line with Unicode recommendations is an important first step, and being conservative about the treatment of operator characters and emoji is a good engineering approach, though certainly unfortunate in the short term for users who've adopted

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

+ on the emoji-related parts, +1 in general spirit, +1 for the identifier cleanup, -103 for being needlessly overly-restrictive for operators; net -1 overall. Operator abuse is a social problem, and even if a technical fix is possible this isn’t that…and despite the messiness of the relevant

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

http://reference.wolfram.com/language/tutorial/Operators.html They’ve been selling products to mathematicians and scientists for decades. Some of those symbols are their own, i.e. not included in unicode. > On Oct 19, 2016, at 8:54 AM, Xiaodi Wu wrote: > > Sorry, I've

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Sorry, I've not been very clear on my question. What non-ASCII operators are in use in your production code? What ASCII equivalents did you consider and discard for those particular operators? It's important to remember that math *symbols* are not all operators. We cannot merely transpose Unicode

  1   2   >