Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

2017-08-08 Thread Taylor Swift via swift-evolution
Real Swift code uses very very few “unicode” operators, so I would heavily tilt the division towards making most characters identifiers. While I don’t want to talk about specific characters, I often wish I could name variables `∇f` or `∂u∂v`, while no sane API designer would ever use `∇` or `∂` as

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

2017-03-01 Thread Jonathan Hull via swift-evolution
As I said before, I am happy with this proposal overall. I just had a strange thought that I thought I should share before this goes through. If we make ‘π’ an operator instead of identifier, then we would be able to write things like 3π directly. For those of us with rational types, we

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

2017-02-27 Thread Xiaodi Wu via swift-evolution
On Mon, Feb 27, 2017 at 10:07 PM, Nevin Brackett-Rozinsky via swift-evolution wrote: > I think the most important goal is to end up with the right set of > operator and identifier characters for *Swift*. The Unicode guidelines are > a useful tool for that purpose, and

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

2017-02-27 Thread Nevin Brackett-Rozinsky via swift-evolution
I think the most important goal is to end up with the right set of operator and identifier characters for *Swift*. The Unicode guidelines are a useful tool for that purpose, and get us a long way toward where we want to be. However at the end of the day we should weigh our success by how well we

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

2017-02-27 Thread Xiaodi Wu via swift-evolution
On Sun, Feb 26, 2017 at 11:50 AM, Nevin Brackett-Rozinsky via swift-evolution wrote: > This looks very good Xiaodi, and I have a few thoughts about it. > > First, is the intent that Swift will follow future changes to Unicode > operator recommendations, or that Swift

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

2017-02-26 Thread Nevin Brackett-Rozinsky via swift-evolution
This looks very good Xiaodi, and I have a few thoughts about it. First, is the intent that Swift will follow future changes to Unicode operator recommendations, or that Swift will choose a “frozen in time” set of Unicode recommendations to adopt? If the former, then we will likely see

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

2017-02-20 Thread Russ Bishop via swift-evolution
> On Feb 16, 2017, at 9:50 PM, Xiaodi Wu via swift-evolution > wrote: > > As Stage 2 of Swift 4 evolution starts now, I'd like to share a revised > proposal in draft form. > > It proposes a source-breaking change for rationalizing which characters are > permitted

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

2017-02-20 Thread Xiaodi Wu via swift-evolution
On Mon, Feb 20, 2017 at 12:29 PM, Alex Blewitt wrote: > > On 17 Feb 2017, at 05:50, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > As Stage 2 of Swift 4 evolution starts now, I'd like to share a revised > proposal in draft form. > > It proposes a

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

2017-02-20 Thread Alex Blewitt via swift-evolution
> On 17 Feb 2017, at 05:50, Xiaodi Wu via swift-evolution > wrote: > > As Stage 2 of Swift 4 evolution starts now, I'd like to share a revised > proposal in draft form. > > It proposes a source-breaking change for rationalizing which characters are > permitted in