Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

After reading the original proposal and the Unicode Annex #31 document that underlies it (https://unicode.org/reports/tr31/) I think that the existing work as an underlying layer could help frame the discussion and push it forward. Although I do see the concerns about defining things too strictly

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On Oct 3, 2017, at 21:47, Chris Lattner mailto:clatt...@nondot.org>> wrote: > >> On Oct 3, 2017, at 4:05 PM, David Sweeris > > wrote: >> >> >>> On Oct 2, 2017, at 10:06 PM, Chris Lattner >> > wrote: >>> >>> On Oct 2, 2017, at 9:12 PM, Da

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On 4 October 2017 at 14:24, Alex Blewitt wrote: func &&&(left: Bool, right: @autoclosure () -> Bool) -> Bool { > return left && right() > } > FTM, it would be nice to be able to "syntax sugar-ize" it into a better looking: func &&& (left: Bool, right: lazy Bool) -> Bool { return left && rig

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On 4 October 2017 at 14:24, Alex Blewitt wrote: > On 4 October 2017 at 13:41, Alex Blewitt wrote: > >> >> The difference between the & and && operators isn't to do with the >> implicit conversions; it's to do with whether both sides of the expression >> are evaluated or not. >> > > However, you

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On 4 Oct 2017, at 14:12, Mike Kluev wrote: > > On 4 October 2017 at 13:41, Alex Blewitt > wrote: > > The difference between the & and && operators isn't to do with the implicit > conversions; it's to do with whether both sides of the expression are > evaluated or no

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On 4 October 2017 at 13:41, Alex Blewitt wrote: > > The difference between the & and && operators isn't to do with the > implicit conversions; it's to do with whether both sides of the expression > are evaluated or not. > > false && system('rm -rf') > > You really don't want to do that if both si

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On 4 Oct 2017, at 13:55, Mike Kluev wrote: > > On 4 October 2017 at 13:41, Alex Blewitt > wrote: >> On 4 Oct 2017, at 11:42, Mike Kluev via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> speaking of &&, was it just a copy-paste from C or is there

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On 4 October 2017 at 13:41, Alex Blewitt wrote: > On 4 Oct 2017, at 11:42, Mike Kluev via swift-evolution < > swift-evolution@swift.org> wrote: > > speaking of &&, was it just a copy-paste from C or is there a more > fundamental reason to use that instead of &? in C they had to use two > differen

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Oct 4, 2017, at 6:41 AM, Alex Blewitt via swift-evolution > wrote: > >> On 4 Oct 2017, at 11:42, Mike Kluev via swift-evolution >> wrote: >> >> on Tue, 3 Oct 2017 11:00:33 -0600 Dave DeLong >> wrote: >> >> > Because, ideally, I’d love to be able to do: >> > >> > infix operator and:

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On 4 Oct 2017, at 11:42, Mike Kluev via swift-evolution > wrote: > > on Tue, 3 Oct 2017 11:00:33 -0600 Dave DeLong > > wrote: > > > Because, ideally, I’d love to be able to do: > > > > infix operator and: LogicalConjunctionPrecedence // or whatever the > > pr

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

on Tue, 3 Oct 2017 11:00:33 -0600 Dave DeLong wrote: > Because, ideally, I’d love to be able to do: > > infix operator and: LogicalConjunctionPrecedence // or whatever the precedence is called > func and(lhs: Bool, rhs: Bool) → Bool { return lhs && rhs } > > let truthyValue = true and false +1

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On Oct 3, 2017, at 5:48 PM, Ethan Tira-Thompson via swift-evolution wrote: >> >> I do think that Ethan’s suggestion upthread interesting, which suggest >> considering something like: >>import matrixlib (operators: [ᵀ,·,⊗]) FWIW, I think you should split discussion of this off into a new su

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Oct 3, 2017, at 4:05 PM, David Sweeris wrote: > > >> On Oct 2, 2017, at 10:06 PM, Chris Lattner > > wrote: >> >> On Oct 2, 2017, at 9:12 PM, David Sweeris via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: Keep in mind that Swift already goe

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On Oct 3, 2017, at 9:43 AM, Félix Cloutier wrote: >> I don’t think this is something we have to try hard to avoid. It is true >> that some characters look similar, particularly in some fonts, but this >> isn’t new: >> >> let a1 = 42 >> let al = 12 >> let b = al + a1 > > There is a fund

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> - Imports are per-module, not per-source-file, so this couldn’t be used to > “user-partition” the identifier and operator space. It could be a way to > make it clear that the user is opting into these explicitly. Imports actually are per-source-file. At times they appear to be per-module be

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Oct 2, 2017, at 10:07 PM, Chris Lattner via swift-evolution > wrote: > > On Oct 2, 2017, at 9:12 PM, David Sweeris via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >>> Keep in mind that Swift already goes far above and beyond in terms of >>> operators >> Yep, that's is a

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Oct 2, 2017, at 10:06 PM, Chris Lattner wrote: > > On Oct 2, 2017, at 9:12 PM, David Sweeris via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >>> Keep in mind that Swift already goes far above and beyond in terms of >>> operators >> Yep, that's is a large part of why I'm su

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

IMO, trying to restrict allowed operator characters based on their visual similarity to other characters is folly. The unicode representation of a character is an independent thing from its visual representation. Because, ideally, I’d love to be able to do: infix operator and: LogicalConjunctio

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> Le 2 oct. 2017 à 21:40, Chris Lattner a écrit : > >> On Oct 2, 2017, at 1:13 AM, Félix Cloutier via swift-evolution >> wrote: >> >> If you tried hard enough, you could probably create a variable that looks >> like it's shadowing one from an outer scope while it actually isn't, and use >>

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On Mon, Oct 2, 2017 at 11:12 PM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > Maybe they've started teaching it earlier than when I went through > school... I don't think I learned it until Discrete Math, which IIRC was a > 2nd or 3rd year course at my college and only r

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On Oct 2, 2017, at 9:12 PM, David Sweeris via swift-evolution wrote: >> Keep in mind that Swift already goes far above and beyond in terms of >> operators > Yep, that's is a large part of why I'm such a Swift fan :-D Fortunately, no one is seriously proposing a major curtailing of the capabili

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On Oct 2, 2017, at 3:24 PM, Xiaodi Wu wrote: >> Especially if people want to use the character in question as both an >> identifier and an operator: We can make the character an identifier and its >> lookalike an operator (or the other way around). > > Off the top of my head... > In calculus, “

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Oct 2, 2017, at 1:13 AM, Félix Cloutier via swift-evolution > wrote: > > If you tried hard enough, you could probably create a variable that looks > like it's shadowing one from an outer scope while it actually isn't, and use > the two to confuse readers. This could trick people into thi

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On Mon, Oct 2, 2017 at 23:11 David Sweeris wrote: > On Oct 2, 2017, at 7:57 PM, Xiaodi Wu wrote: > > On Mon, Oct 2, 2017 at 9:04 PM, David Sweeris wrote: > >> >> On Oct 2, 2017, at 5:45 PM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> On Mon, Oct 2, 2017 at 19:28 E

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Oct 2, 2017, at 7:57 PM, Xiaodi Wu wrote: > > On Mon, Oct 2, 2017 at 9:04 PM, David Sweeris > wrote: > > On Oct 2, 2017, at 5:45 PM, Xiaodi Wu via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Mon, Oct 2, 2017 at 19:28 Ethan Tira-Thompso

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On Mon, Oct 2, 2017 at 9:04 PM, David Sweeris wrote: > > On Oct 2, 2017, at 5:45 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Mon, Oct 2, 2017 at 19:28 Ethan Tira-Thompson via swift-evolution < > swift-evolution@swift.org> wrote: > >> I’m all for fixing pressing

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Oct 2, 2017, at 5:45 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Mon, Oct 2, 2017 at 19:28 Ethan Tira-Thompson via swift-evolution >> wrote: >> I’m all for fixing pressing issues requested by Xiaodi, but beyond that I >> request we give a little more thought to the long term dire

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Oct 2, 2017, at 3:24 PM, Xiaodi Wu wrote: > >> On Mon, Oct 2, 2017 at 12:58 PM, David Sweeris wrote: >> >>> On Oct 2, 2017, at 09:14, Xiaodi Wu wrote: >>> >>> What is your use case for this? >>> On Mon, Oct 2, 2017 at 10:56 David Sweeris via swift-evolution wrote: >>>

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On Mon, Oct 2, 2017 at 19:28 Ethan Tira-Thompson via swift-evolution < swift-evolution@swift.org> wrote: > I’m all for fixing pressing issues requested by Xiaodi, but beyond that I > request we give a little more thought to the long term direction. > > My 2¢ is I’ve been convinced that very few ch

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

Ethan- This is brilliant. I don’t know if it’s technically feasible, but this is how it *should be.* - Jonathan > On Oct 2, 2017, at 17:28, Ethan Tira-Thompson via swift-evolution > wrote: > > I’m all for fixing pressing issues requested by Xiaodi, but beyond that I > request we give a litt

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

I’m all for fixing pressing issues requested by Xiaodi, but beyond that I request we give a little more thought to the long term direction. My 2¢ is I’ve been convinced that very few characters are “obviously” either a operator or identifier across all contexts where they might be used. Thus r

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On Mon, Oct 2, 2017 at 12:58 PM, David Sweeris wrote: > > On Oct 2, 2017, at 09:14, Xiaodi Wu wrote: > > What is your use case for this? > > On Mon, Oct 2, 2017 at 10:56 David Sweeris via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> On Oct 1, 2017, at 22:01, Chris Lattner via sw

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On Oct 2, 2017, at 09:14, Xiaodi Wu mailto:xiaodi...@gmail.com>> wrote: > What is your use case for this? > > On Mon, Oct 2, 2017 at 10:56 David Sweeris via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution > mailto:swi

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

What is your use case for this? On Mon, Oct 2, 2017 at 10:56 David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolutio

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution > wrote: > > >> On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution >> wrote: >> >> Hi All. >> >> I’d like to help as well. I have fun with operators. >> >> There is also the issue of code security with invisible unicod

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On 02.10.2017 8:30, Kenny Leung via swift-evolution wrote: I guess theoretically you could have two variables that look alike, but are actually different values, allowing you to insert some obfuscated malicious code somehow. Also, IIRC, there is a "similar" problem exists with Right-To-Left "

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

This is why I’m advocating for the sections of the previous draft that deal with this issue to be maintained going forward. In that document and in the links provided in that document, there are very extensive previous discussions on lookalike characters and invisibles. No need to rehash this very

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

If you tried hard enough, you could probably create a variable that looks like it's shadowing one from an outer scope while it actually isn't, and use the two to confuse readers. This could trick people into thinking that some dangerous/backdoor code is actually good and safe, especially in the

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

I guess theoretically you could have two variables that look alike, but are actually different values, allowing you to insert some obfuscated malicious code somehow. -Kenny > On Oct 1, 2017, at 10:01 PM, Chris Lattner wrote: > >> >> On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolutio

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution > wrote: > > Hi All. > > I’d like to help as well. I have fun with operators. > > There is also the issue of code security with invisible unicode characters > and characters that look exactly alike. Unless there is a compelling r

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

Hi All. I’d like to help as well. I have fun with operators. There is also the issue of code security with invisible unicode characters and characters that look exactly alike. (They should make a Coding font that ensures all characters look different.) Was that ever resolved? Googling, I found

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Oct 1, 2017, at 16:50, Chris Lattner wrote: > > >> On Oct 1, 2017, at 4:30 PM, Matt Whiteside via swift-evolution >> wrote: >> >> >> >>> That said, it’s unclear to me that superscript T is clearly an operator, >>> any more than would be superscript H (Hermitian), superscript 2, >>>

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Sep 30, 2017, at 4:12 PM, Xiaodi Wu wrote: > > I’m happy to participate in the reshaping of the proposal. It would be nice > to gather a group of people again to help drive it forward. Awesome, thank you! > That said, it’s unclear to me that superscript T is clearly an operator, any > m

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Oct 1, 2017, at 4:30 PM, Matt Whiteside via swift-evolution > wrote: > > > >> That said, it’s unclear to me that superscript T is clearly an operator, any >> more than would be superscript H (Hermitian), superscript 2, superscript 3, >> etc. But at any rate, this would be discussion fo

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> That said, it’s unclear to me that superscript T is clearly an operator, any > more than would be superscript H (Hermitian), superscript 2, superscript 3, > etc. But at any rate, this would be discussion for the future Allowing superscripted characters to be used as operators seems like it

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

Understood. Thanks, Jon > On Oct 1, 2017, at 4:20 PM, Chris Lattner wrote: > > Something like that is possible, but makes the language/compiler more > complicated by introducing a whole new concept to the source distribution. > It also doesn’t address the cases where you want to do a parse b

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

Something like that is possible, but makes the language/compiler more complicated by introducing a whole new concept to the source distribution. It also doesn’t address the cases where you want to do a parse but don’t have the dependent source files, e.g. in a source browser tool like ViewVC.

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

Gotcha. What if the definitions were in a special file similar to the info.plist that was read before other parsing, with one file per package? Thanks, Jon > On Oct 1, 2017, at 4:09 PM, Chris Lattner wrote: > > On Sep 30, 2017, at 7:10 PM, Jonathan Hull wrote: >> I have a technical question

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On Sep 30, 2017, at 7:10 PM, Jonathan Hull wrote: > I have a technical question on this: > > Instead of parsing these into identifiers & operators, would it be possible > to parse these into 3 categories: Identifiers, Operators, and Ambiguous? > > The ambiguous category would be disallowed for

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

It won’t compile. > On Sep 30, 2017, at 7:14 PM, Taylor Swift wrote: > > what happens if two public operator declarations conflict? > > On Sat, Sep 30, 2017 at 9:10 PM, Jonathan Hull via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > I have a technical question on this: > > Ins

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

what happens if two public operator declarations conflict? On Sat, Sep 30, 2017 at 9:10 PM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > I have a technical question on this: > > Instead of parsing these into identifiers & operators, would it be > possible to parse these

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

I have a technical question on this: Instead of parsing these into identifiers & operators, would it be possible to parse these into 3 categories: Identifiers, Operators, and Ambiguous? The ambiguous category would be disallowed for the moment, as you say. But since they are rarely used, maybe

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On Sat, Sep 30, 2017 at 18:59 David Sweeris wrote: > > On Sep 30, 2017, at 16:13, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > I’m happy to participate in the reshaping of the proposal. It would be > nice to gather a group of people again to help drive it forward. > > T

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Sep 30, 2017, at 16:13, Xiaodi Wu via swift-evolution > wrote: > > I’m happy to participate in the reshaping of the proposal. It would be nice > to gather a group of people again to help drive it forward. > > That said, it’s unclear to me that superscript T is clearly an operator, any >

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

I’m happy to participate in the reshaping of the proposal. It would be nice to gather a group of people again to help drive it forward. That said, it’s unclear to me that superscript T is clearly an operator, any more than would be superscript H (Hermitian), superscript 2, superscript 3, etc. But

[swift-evolution] A path forward on rationalizing unicode identifiers and operators

The core team recently met to discuss PR609 - Refining identifier and operator symbology: https://github.com/xwu/swift-evolution/blob/7c2c4df63b1d92a1677461f41bc638f31926c9c3/proposals/-refining-identifier-and-operator-symbology.md The proposal correctly observes that the partitioning of uni