define backslash '\' as a operator-head in the swift grammar


(Nicolas Fezans) #1

Dear all,

This is a rather simple proposal to add '\' (backslash character) as a
valid operator-head in the swift grammar.

One argument for it, is that there exist a backslash operator in the
MATLAB/Scilab/Octave languages. In this languages A\B solves the linear
system A*X = B for X (or the least square problem associated to it if the
system of equations is overdetermined). I am doing some numerical
computation in Swift and it would be nice to be able to declare the same
operator name for this functionality.

I might have missed some arguments for not adding them, but I seems to me
that until now the \ character is only used inside of string literals. If
that is the case, both uses should never generate a conflict or be
ambiguous, isn't it? (String literals keep their interpretation of \ and \
used otherwise within the swift code will be interpreted as an operator or
as the beginning of an operator)

I am curious to see what will be the feedback on this.

Nicolas


(Dave Abrahams) #2

+1 if it doesn't clash with the grammar.

···

on Sun Feb 05 2017, Nicolas Fezans <swift-evolution@swift.org> wrote:

Dear all,

This is a rather simple proposal to add '\' (backslash character) as a
valid operator-head in the swift grammar.

One argument for it, is that there exist a backslash operator in the
MATLAB/Scilab/Octave languages. In this languages A\B solves the linear
system A*X = B for X (or the least square problem associated to it if the
system of equations is overdetermined). I am doing some numerical
computation in Swift and it would be nice to be able to declare the same
operator name for this functionality.

I might have missed some arguments for not adding them, but I seems to me
that until now the \ character is only used inside of string literals. If
that is the case, both uses should never generate a conflict or be
ambiguous, isn't it? (String literals keep their interpretation of \ and \
used otherwise within the swift code will be interpreted as an operator or
as the beginning of an operator)

I am curious to see what will be the feedback on this.

--
-Dave


(Derrick Ho) #3

If the \ operator is not defined in swift, does it treat it as something
that can be operator overloaded?

···

On Sun, Feb 5, 2017 at 10:29 AM Nicolas Fezans via swift-evolution < swift-evolution@swift.org> wrote:

Dear all,

This is a rather simple proposal to add '\' (backslash character) as a
valid operator-head in the swift grammar.

One argument for it, is that there exist a backslash operator in the
MATLAB/Scilab/Octave languages. In this languages A\B solves the linear
system A*X = B for X (or the least square problem associated to it if the
system of equations is overdetermined). I am doing some numerical
computation in Swift and it would be nice to be able to declare the same
operator name for this functionality.

I might have missed some arguments for not adding them, but I seems to me
that until now the \ character is only used inside of string literals. If
that is the case, both uses should never generate a conflict or be
ambiguous, isn't it? (String literals keep their interpretation of \ and \
used otherwise within the swift code will be interpreted as an operator or
as the beginning of an operator)

I am curious to see what will be the feedback on this.

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


#4

+1 as well. I also support adding these four symbols: ⅀ ؆ ؇ ⅋ as operators.

There was substantial discussion last fall about revamping operators in
Swift, with the primary goal of removing characters that should not be in
the set. I went through the Unicode tables and compiled a list of 1,020
characters that I think definitely should be operators [list of operator
characters
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[[%3ASm%3A] -\p{Block%3DSuperscripts+And+Subscripts} -\p{Block%3DMiscellaneous+Technical} -\p{Block%3DGeometric+Shapes} -\p{Block%3DMiscellaneous+Symbols} -\p{Block%3DAlphabetic+Presentation+Forms} -\p{Block%3DSmall+Form+Variants} -\p{Block%3DHalfwidth+And+Fullwidth+Forms} -\p{Block%3DMathematical+Alphanumeric+Symbols} -\p{Block%3DArabic+Mathematical+Alphabetic+Symbols} -\p{subhead%3DVariant+letterforms+and+symbols} -\p{subhead%3DLetterlike+symbol} \p{Block%3DArrows} [%2F+%3D+\-+%2B+!+*+%+<+>+\%26+|+\^+~+%3F] [¡+¢+£+¤+¥+¦+§+©+«+¬+®+°+±+¶+»+¿]+-+[¢+£+¤+¥+©+®] \p{subhead%3DGeneral+punctuation}+-+[U%2B203F+U%2B2040+U%2B2045+U%2B2046+U%2B2054] \p{subhead%3DDouble+punctuation+for+vertical+text} \p{subhead%3DArchaic+punctuation}+-+[U%2B2E31+U%2B2E33+U%2B2E34+U%2B2E3F] U%2B214B]&g=&i=>
]

The effect of that would be to make 1,628 characters no longer usable as
operators [list of non-operator characters
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[%2F+%3D+\-+%2B+!++%25+%3C+%3E+%5C%26+%7C+%5C%5E+~+%3F%0D%0AU%2B00A1±+U%2B00A7%0D%0AU%2B00A9+U%2B00AB+U%2B00AC+U%2B00AE%0D%0AU%2B00B0±+U%2B00B1%0D%0AU%2B00B6+U%2B00BB+U%2B00BF+U%2B00D7+U%2B00F7%0D%0AU%2B2016±+U%2B2017%0D%0AU%2B2020±+U%2B2027%0D%0AU%2B2030±+U%2B203E%0D%0AU%2B2041±+U%2B2053%0D%0AU%2B2055±+U%2B205E%0D%0AU%2B2190±+U%2B23FF%0D%0AU%2B2500±+U%2B2775%0D%0AU%2B2794±+U%2B2BFF%0D%0AU%2B2E00±+U%2B2E7F%0D%0AU%2B3001±+U%2B3003%0D%0AU%2B3008±+U%2B3030%5D%0D%0A%0D%0A-%5B%5B%3ASm%3A%5D%0D%0A-%5Cp%7BBlock%3DSuperscripts+And+Subscripts%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Technical%7D%0D%0A-%5Cp%7BBlock%3DGeometric+Shapes%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Symbols%7D%0D%0A-%5Cp%7BBlock%3DAlphabetic+Presentation+Forms%7D%0D%0A-%5Cp%7BBlock%3DSmall+Form+Variants%7D%0D%0A-%5Cp%7BBlock%3DHalfwidth+And+Fullwidth+Forms%7D%0D%0A-%5Cp%7BBlock%3DMathematical+Alphanumeric+Symbols%7D%0D%0A-%5Cp%7BBlock%3DArabic+Mathematical+Alphabetic+Symbols%7D%0D%0A-%5Cp%7Bsubhead%3DVariant+letterforms+and+symbols%7D%0D%0A-%5Cp%7Bsubhead%3DLetterlike+symbol%7D%0D%0A%5Cp%7BBlock%3DArrows%7D%0D%0A%5B%2F+%3D+%5C-+%2B+%21++%25+%3C+%3E+%5C%26+%7C+%5C%5E+~+%3F%5D%0D%0A%5B%C2%A1+%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A6+%C2%A7+%C2%A9+%C2%AB+%C2%AC+%C2%AE+%C2%B0+%C2%B1+%C2%B6+%C2%BB+%C2%BF%5D±+%5B%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A9+%C2%AE%5D%0D%0A%5Cp%7Bsubhead%3DGeneral+punctuation%7D±+%5BU%2B203F+U%2B2040+U%2B2045+U%2B2046+U%2B2054%5D%0D%0A%5Cp%7Bsubhead%3DDouble+punctuation+for+vertical+text%7D%0D%0A%5Cp%7Bsubhead%3DArchaic+punctuation%7D±+%5BU%2B2E31+U%2B2E33+U%2B2E34+U%2B2E3F%5D%0D%0AU%2B214B%5D&g=&i=>
]

However, my strategy was to be conservative in accepting operators. There
are several Unicode blocks which contain some additional characters which
we may want to have as operators [list of characters in those blocks
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[\p{Block%3DMiscellaneous+Technical} \p{Block%3DOptical+Character+Recognition} \p{Block%3DBox+Drawing} \p{Block%3DBlock+Elements} \p{Block%3DGeometric+Shapes} \p{Block%3DMiscellaneous+Symbols} \p{Block%3DDingbats} \p{Block%3DBraille} \p{Block%3DMiscellaneous+Symbols+And+Arrows} \p{Block%3DYijing+Hexagram+Symbols} \p{Block%3DMusical+Symbols} \p{Block%3DAncient+Greek+Musical+Notation} \p{Block%3DTai+Xuan+Jing+Symbols} \p{Block%3DMahjong+Tiles} \p{Block%3DDomino+Tiles} \p{Block%3DPlaying+Cards} \p{Block%3DOrnamental+Dingbats} \p{Block%3DAlchemical+Symbols} \p{Block%3DGeometric+Shapes+Extended} \p{Block%3DSupplemental+Arrows+C}] &g=&i=>
]

I did not include the backslash because I decided not to mess with the
choice of ASCII operators, however I do support making backslash an
operator. I am not sure about currency symbols.

Nevin

···

On Sun, Feb 5, 2017 at 1:20 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote:

on Sun Feb 05 2017, Nicolas Fezans <swift-evolution@swift.org> wrote:

> Dear all,
>
> This is a rather simple proposal to add '\' (backslash character) as a
> valid operator-head in the swift grammar.
>
> One argument for it, is that there exist a backslash operator in the
> MATLAB/Scilab/Octave languages. In this languages A\B solves the linear
> system A*X = B for X (or the least square problem associated to it if the
> system of equations is overdetermined). I am doing some numerical
> computation in Swift and it would be nice to be able to declare the same
> operator name for this functionality.
>
> I might have missed some arguments for not adding them, but I seems to me
> that until now the \ character is only used inside of string literals. If
> that is the case, both uses should never generate a conflict or be
> ambiguous, isn't it? (String literals keep their interpretation of \ and
\
> used otherwise within the swift code will be interpreted as an operator
or
> as the beginning of an operator)
>
> I am curious to see what will be the feedback on this.

+1 if it doesn't clash with the grammar.

--
-Dave

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


(Nicolas Fezans) #5

Well you cannot define it because the \ character itself is not allowed
outside of a string.
If you try to declare it with

infix operator \

you get an error "Invalid character in source file" in Xcode and where you
define the function itself you have the same error.

This would not happen if it was part of the allowed operator-head
characters. Here is the grammar of operator for Swift 3.0.1 (from
https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/zzSummaryOfTheGrammar.html
)

GRAMMAR OF OPERATORS
operator → operator-head­operator-characters­opt­
operator → dot-operator-head­dot-operator-characters­

operator-head → /­ =­ -­ +­ !­ *­ %­ <­ >­ &­ |­ ^­ ~­ ?­
operator-head → U+00A1–U+00A7
operator-head → U+00A9 or U+00AB
operator-head → U+00AC or U+00AE
operator-head → U+00B0–U+00B1, U+00B6, U+00BB, U+00BF, U+00D7, or U+00F7
operator-head → U+2016–U+2017 or U+2020–U+2027
operator-head → U+2030–U+203E
operator-head → U+2041–U+2053
operator-head → U+2055–U+205E
operator-head → U+2190–U+23FF
operator-head → U+2500–U+2775
operator-head → U+2794–U+2BFF
operator-head → U+2E00–U+2E7F
operator-head → U+3001–U+3003
operator-head → U+3008–U+3030

operator-character → operator-head­
operator-character → U+0300–U+036F
operator-character → U+1DC0–U+1DFF
operator-character → U+20D0–U+20FF
operator-character → U+FE00–U+FE0F
operator-character → U+FE20–U+FE2F
operator-character → U+E0100–U+E01EF
operator-characters → operator-character­operator-characters­opt­

dot-operator-head → .­
dot-operator-character → .­ operator-character­
dot-operator-characters →
dot-operator-character­dot-operator-characters­opt­

binary-operator → operator­
prefix-operator → operator­
postfix-operator → operator­

The change I propose would basically lead to have
operator-head → /­ =­ -­ +­ !­ *­ %­ <­ >­ &­ |­ ^­ ~­ ?­ \

instead of the line

operator-head → /­ =­ -­ +­ !­ *­ %­ <­ >­ &­ |­ ^­ ~­ ?­

in the swift grammar.

Nicolas

wi

···

On Sun, Feb 5, 2017 at 4:55 PM, Derrick Ho <wh1pch81n@gmail.com> wrote:

If the \ operator is not defined in swift, does it treat it as something
that can be operator overloaded?

On Sun, Feb 5, 2017 at 10:29 AM Nicolas Fezans via swift-evolution < > swift-evolution@swift.org> wrote:

Dear all,

This is a rather simple proposal to add '\' (backslash character) as a
valid operator-head in the swift grammar.

One argument for it, is that there exist a backslash operator in the
MATLAB/Scilab/Octave languages. In this languages A\B solves the linear
system A*X = B for X (or the least square problem associated to it if the
system of equations is overdetermined). I am doing some numerical
computation in Swift and it would be nice to be able to declare the same
operator name for this functionality.

I might have missed some arguments for not adding them, but I seems to me
that until now the \ character is only used inside of string literals. If
that is the case, both uses should never generate a conflict or be
ambiguous, isn't it? (String literals keep their interpretation of \ and \
used otherwise within the swift code will be interpreted as an operator or
as the beginning of an operator)

I am curious to see what will be the feedback on this.

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


(Chris Lattner) #6

+1 from me, I agree with downthread comments that it would be really really really great to get the unicode operator situation sorted out in Swift 4.

-Chris

···

On Feb 5, 2017, at 7:29 AM, Nicolas Fezans via swift-evolution <swift-evolution@swift.org> wrote:

Dear all,

This is a rather simple proposal to add '\' (backslash character) as a valid operator-head in the swift grammar.


(Slava Pestov) #7

I really have nothing to add to this discussion, except for this fun fact: apparently, the backslash was added to ASCII so you could write /\ and \/ operators: http://www.bobbemer.com/BACSLASH.HTM

Slava

···

On Feb 5, 2017, at 7:29 AM, Nicolas Fezans via swift-evolution <swift-evolution@swift.org> wrote:

Dear all,

This is a rather simple proposal to add '\' (backslash character) as a valid operator-head in the swift grammar.

One argument for it, is that there exist a backslash operator in the MATLAB/Scilab/Octave languages. In this languages A\B solves the linear system A*X = B for X (or the least square problem associated to it if the system of equations is overdetermined). I am doing some numerical computation in Swift and it would be nice to be able to declare the same operator name for this functionality.

I might have missed some arguments for not adding them, but I seems to me that until now the \ character is only used inside of string literals. If that is the case, both uses should never generate a conflict or be ambiguous, isn't it? (String literals keep their interpretation of \ and \ used otherwise within the swift code will be interpreted as an operator or as the beginning of an operator)

I am curious to see what will be the feedback on this.

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


(TJ Usiyan) #8

+1 from me.

I hope that operators get more work soon, especially with regard to math.

···

On Sun, Feb 5, 2017 at 5:09 PM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution@swift.org> wrote:

+1 as well. I also support adding these four symbols: ⅀ ؆ ؇ ⅋ as
operators.

There was substantial discussion last fall about revamping operators in
Swift, with the primary goal of removing characters that should not be in
the set. I went through the Unicode tables and compiled a list of 1,020
characters that I think definitely should be operators [list of operator
characters
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[[%3ASm%3A] -\p{Block%3DSuperscripts+And+Subscripts} -\p{Block%3DMiscellaneous+Technical} -\p{Block%3DGeometric+Shapes} -\p{Block%3DMiscellaneous+Symbols} -\p{Block%3DAlphabetic+Presentation+Forms} -\p{Block%3DSmall+Form+Variants} -\p{Block%3DHalfwidth+And+Fullwidth+Forms} -\p{Block%3DMathematical+Alphanumeric+Symbols} -\p{Block%3DArabic+Mathematical+Alphabetic+Symbols} -\p{subhead%3DVariant+letterforms+and+symbols} -\p{subhead%3DLetterlike+symbol} \p{Block%3DArrows} [%2F+%3D+\-+%2B+!+*+%+<+>+\%26+|+\^+~+%3F] [¡+¢+£+¤+¥+¦+§+©+«+¬+®+°+±+¶+»+¿]+-+[¢+£+¤+¥+©+®] \p{subhead%3DGeneral+punctuation}+-+[U%2B203F+U%2B2040+U%2B2045+U%2B2046+U%2B2054] \p{subhead%3DDouble+punctuation+for+vertical+text} \p{subhead%3DArchaic+punctuation}+-+[U%2B2E31+U%2B2E33+U%2B2E34+U%2B2E3F] U%2B214B]&g=&i=>
]

The effect of that would be to make 1,628 characters no longer usable as
operators [list of non-operator characters
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[%2F+%3D+\-+%2B+!++%25+%3C+%3E+%5C%26+%7C+%5C%5E+~+%3F%0D%0AU%2B00A1±+U%2B00A7%0D%0AU%2B00A9+U%2B00AB+U%2B00AC+U%2B00AE%0D%0AU%2B00B0±+U%2B00B1%0D%0AU%2B00B6+U%2B00BB+U%2B00BF+U%2B00D7+U%2B00F7%0D%0AU%2B2016±+U%2B2017%0D%0AU%2B2020±+U%2B2027%0D%0AU%2B2030±+U%2B203E%0D%0AU%2B2041±+U%2B2053%0D%0AU%2B2055±+U%2B205E%0D%0AU%2B2190±+U%2B23FF%0D%0AU%2B2500±+U%2B2775%0D%0AU%2B2794±+U%2B2BFF%0D%0AU%2B2E00±+U%2B2E7F%0D%0AU%2B3001±+U%2B3003%0D%0AU%2B3008±+U%2B3030%5D%0D%0A%0D%0A-%5B%5B%3ASm%3A%5D%0D%0A-%5Cp%7BBlock%3DSuperscripts+And+Subscripts%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Technical%7D%0D%0A-%5Cp%7BBlock%3DGeometric+Shapes%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Symbols%7D%0D%0A-%5Cp%7BBlock%3DAlphabetic+Presentation+Forms%7D%0D%0A-%5Cp%7BBlock%3DSmall+Form+Variants%7D%0D%0A-%5Cp%7BBlock%3DHalfwidth+And+Fullwidth+Forms%7D%0D%0A-%5Cp%7BBlock%3DMathematical+Alphanumeric+Symbols%7D%0D%0A-%5Cp%7BBlock%3DArabic+Mathematical+Alphabetic+Symbols%7D%0D%0A-%5Cp%7Bsubhead%3DVariant+letterforms+and+symbols%7D%0D%0A-%5Cp%7Bsubhead%3DLetterlike+symbol%7D%0D%0A%5Cp%7BBlock%3DArrows%7D%0D%0A%5B%2F+%3D+%5C-+%2B+%21++%25+%3C+%3E+%5C%26+%7C+%5C%5E+~+%3F%5D%0D%0A%5B%C2%A1+%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A6+%C2%A7+%C2%A9+%C2%AB+%C2%AC+%C2%AE+%C2%B0+%C2%B1+%C2%B6+%C2%BB+%C2%BF%5D±+%5B%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A9+%C2%AE%5D%0D%0A%5Cp%7Bsubhead%3DGeneral+punctuation%7D±+%5BU%2B203F+U%2B2040+U%2B2045+U%2B2046+U%2B2054%5D%0D%0A%5Cp%7Bsubhead%3DDouble+punctuation+for+vertical+text%7D%0D%0A%5Cp%7Bsubhead%3DArchaic+punctuation%7D±+%5BU%2B2E31+U%2B2E33+U%2B2E34+U%2B2E3F%5D%0D%0AU%2B214B%5D&g=&i=>
]

However, my strategy was to be conservative in accepting operators. There
are several Unicode blocks which contain some additional characters which
we may want to have as operators [list of characters in those blocks
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[\p{Block%3DMiscellaneous+Technical} \p{Block%3DOptical+Character+Recognition} \p{Block%3DBox+Drawing} \p{Block%3DBlock+Elements} \p{Block%3DGeometric+Shapes} \p{Block%3DMiscellaneous+Symbols} \p{Block%3DDingbats} \p{Block%3DBraille} \p{Block%3DMiscellaneous+Symbols+And+Arrows} \p{Block%3DYijing+Hexagram+Symbols} \p{Block%3DMusical+Symbols} \p{Block%3DAncient+Greek+Musical+Notation} \p{Block%3DTai+Xuan+Jing+Symbols} \p{Block%3DMahjong+Tiles} \p{Block%3DDomino+Tiles} \p{Block%3DPlaying+Cards} \p{Block%3DOrnamental+Dingbats} \p{Block%3DAlchemical+Symbols} \p{Block%3DGeometric+Shapes+Extended} \p{Block%3DSupplemental+Arrows+C}] &g=&i=>
]

I did not include the backslash because I decided not to mess with the
choice of ASCII operators, however I do support making backslash an
operator. I am not sure about currency symbols.

Nevin

On Sun, Feb 5, 2017 at 1:20 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:

on Sun Feb 05 2017, Nicolas Fezans <swift-evolution@swift.org> wrote:

> Dear all,
>
> This is a rather simple proposal to add '\' (backslash character) as a
> valid operator-head in the swift grammar.
>
> One argument for it, is that there exist a backslash operator in the
> MATLAB/Scilab/Octave languages. In this languages A\B solves the linear
> system A*X = B for X (or the least square problem associated to it if
the
> system of equations is overdetermined). I am doing some numerical
> computation in Swift and it would be nice to be able to declare the same
> operator name for this functionality.
>
> I might have missed some arguments for not adding them, but I seems to
me
> that until now the \ character is only used inside of string literals.
If
> that is the case, both uses should never generate a conflict or be
> ambiguous, isn't it? (String literals keep their interpretation of \
and \
> used otherwise within the swift code will be interpreted as an operator
or
> as the beginning of an operator)
>
> I am curious to see what will be the feedback on this.

+1 if it doesn't clash with the grammar.

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


(David Hart) #9

And the overjoyed operator: \o/

···

On 7 Feb 2017, at 08:04, Slava Pestov via swift-evolution <swift-evolution@swift.org> wrote:

I really have nothing to add to this discussion, except for this fun fact: apparently, the backslash was added to ASCII so you could write /\ and \/ operators: http://www.bobbemer.com/BACSLASH.HTM

Slava

On Feb 5, 2017, at 7:29 AM, Nicolas Fezans via swift-evolution <swift-evolution@swift.org> wrote:

Dear all,

This is a rather simple proposal to add '\' (backslash character) as a valid operator-head in the swift grammar.

One argument for it, is that there exist a backslash operator in the MATLAB/Scilab/Octave languages. In this languages A\B solves the linear system A*X = B for X (or the least square problem associated to it if the system of equations is overdetermined). I am doing some numerical computation in Swift and it would be nice to be able to declare the same operator name for this functionality.

I might have missed some arguments for not adding them, but I seems to me that until now the \ character is only used inside of string literals. If that is the case, both uses should never generate a conflict or be ambiguous, isn't it? (String literals keep their interpretation of \ and \ used otherwise within the swift code will be interpreted as an operator or as the beginning of an operator)

I am curious to see what will be the feedback on this.

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


(Xiaodi Wu) #10

IIRC, where we left the discussion last time was that there was work not
yet complete within Unicode on delineating identifier and operator
characters. As there was broad agreement to align identifier characters
with Unicode standards, and since the strict separation between identifiers
and operators means that no character should belong to both, there was
hesitation to declare an operator what Unicode may later deem to be an
identifier.

There was strenuous objection to temporarily cutting back operators to the
ASCII range until Unicode completes its work, but also pushback in going
character-by-character above the ASCII range.

In any case, \ seems perfectly reasonable as an additional operator
character that doesn't have to wait for Unicode.

···

On Sun, Feb 5, 2017 at 19:02 T.J. Usiyan via swift-evolution < swift-evolution@swift.org> wrote:

+1 from me.

I hope that operators get more work soon, especially with regard to math.

On Sun, Feb 5, 2017 at 5:09 PM, Nevin Brackett-Rozinsky via > swift-evolution <swift-evolution@swift.org> wrote:

+1 as well. I also support adding these four symbols: ⅀ ؆ ؇ ⅋ as
operators.

There was substantial discussion last fall about revamping operators in
Swift, with the primary goal of removing characters that should not be in
the set. I went through the Unicode tables and compiled a list of 1,020
characters that I think definitely should be operators [list of operator
characters
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[[%3ASm%3A] -\p{Block%3DSuperscripts+And+Subscripts} -\p{Block%3DMiscellaneous+Technical} -\p{Block%3DGeometric+Shapes} -\p{Block%3DMiscellaneous+Symbols} -\p{Block%3DAlphabetic+Presentation+Forms} -\p{Block%3DSmall+Form+Variants} -\p{Block%3DHalfwidth+And+Fullwidth+Forms} -\p{Block%3DMathematical+Alphanumeric+Symbols} -\p{Block%3DArabic+Mathematical+Alphabetic+Symbols} -\p{subhead%3DVariant+letterforms+and+symbols} -\p{subhead%3DLetterlike+symbol} \p{Block%3DArrows} [%2F+%3D+\-+%2B+!+*+%+<+>+\%26+|+\^+~+%3F] [¡+¢+£+¤+¥+¦+§+©+«+¬+®+°+±+¶+»+¿]+-+[¢+£+¤+¥+©+®] \p{subhead%3DGeneral+punctuation}+-+[U%2B203F+U%2B2040+U%2B2045+U%2B2046+U%2B2054] \p{subhead%3DDouble+punctuation+for+vertical+text} \p{subhead%3DArchaic+punctuation}+-+[U%2B2E31+U%2B2E33+U%2B2E34+U%2B2E3F] U%2B214B]&g=&i=>
]

The effect of that would be to make 1,628 characters no longer usable as
operators [list of non-operator characters
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[%2F+%3D+\-+%2B+!++%25+%3C+%3E+%5C%26+%7C+%5C%5E+~+%3F%0D%0AU%2B00A1±+U%2B00A7%0D%0AU%2B00A9+U%2B00AB+U%2B00AC+U%2B00AE%0D%0AU%2B00B0±+U%2B00B1%0D%0AU%2B00B6+U%2B00BB+U%2B00BF+U%2B00D7+U%2B00F7%0D%0AU%2B2016±+U%2B2017%0D%0AU%2B2020±+U%2B2027%0D%0AU%2B2030±+U%2B203E%0D%0AU%2B2041±+U%2B2053%0D%0AU%2B2055±+U%2B205E%0D%0AU%2B2190±+U%2B23FF%0D%0AU%2B2500±+U%2B2775%0D%0AU%2B2794±+U%2B2BFF%0D%0AU%2B2E00±+U%2B2E7F%0D%0AU%2B3001±+U%2B3003%0D%0AU%2B3008±+U%2B3030%5D%0D%0A%0D%0A-%5B%5B%3ASm%3A%5D%0D%0A-%5Cp%7BBlock%3DSuperscripts+And+Subscripts%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Technical%7D%0D%0A-%5Cp%7BBlock%3DGeometric+Shapes%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Symbols%7D%0D%0A-%5Cp%7BBlock%3DAlphabetic+Presentation+Forms%7D%0D%0A-%5Cp%7BBlock%3DSmall+Form+Variants%7D%0D%0A-%5Cp%7BBlock%3DHalfwidth+And+Fullwidth+Forms%7D%0D%0A-%5Cp%7BBlock%3DMathematical+Alphanumeric+Symbols%7D%0D%0A-%5Cp%7BBlock%3DArabic+Mathematical+Alphabetic+Symbols%7D%0D%0A-%5Cp%7Bsubhead%3DVariant+letterforms+and+symbols%7D%0D%0A-%5Cp%7Bsubhead%3DLetterlike+symbol%7D%0D%0A%5Cp%7BBlock%3DArrows%7D%0D%0A%5B%2F+%3D+%5C-+%2B+%21++%25+%3C+%3E+%5C%26+%7C+%5C%5E+~+%3F%5D%0D%0A%5B%C2%A1+%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A6+%C2%A7+%C2%A9+%C2%AB+%C2%AC+%C2%AE+%C2%B0+%C2%B1+%C2%B6+%C2%BB+%C2%BF%5D±+%5B%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A9+%C2%AE%5D%0D%0A%5Cp%7Bsubhead%3DGeneral+punctuation%7D±+%5BU%2B203F+U%2B2040+U%2B2045+U%2B2046+U%2B2054%5D%0D%0A%5Cp%7Bsubhead%3DDouble+punctuation+for+vertical+text%7D%0D%0A%5Cp%7Bsubhead%3DArchaic+punctuation%7D±+%5BU%2B2E31+U%2B2E33+U%2B2E34+U%2B2E3F%5D%0D%0AU%2B214B%5D&g=&i=>
]

However, my strategy was to be conservative in accepting operators. There
are several Unicode blocks which contain some additional characters which
we may want to have as operators [list of characters in those blocks
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[\p{Block%3DMiscellaneous+Technical} \p{Block%3DOptical+Character+Recognition} \p{Block%3DBox+Drawing} \p{Block%3DBlock+Elements} \p{Block%3DGeometric+Shapes} \p{Block%3DMiscellaneous+Symbols} \p{Block%3DDingbats} \p{Block%3DBraille} \p{Block%3DMiscellaneous+Symbols+And+Arrows} \p{Block%3DYijing+Hexagram+Symbols} \p{Block%3DMusical+Symbols} \p{Block%3DAncient+Greek+Musical+Notation} \p{Block%3DTai+Xuan+Jing+Symbols} \p{Block%3DMahjong+Tiles} \p{Block%3DDomino+Tiles} \p{Block%3DPlaying+Cards} \p{Block%3DOrnamental+Dingbats} \p{Block%3DAlchemical+Symbols} \p{Block%3DGeometric+Shapes+Extended} \p{Block%3DSupplemental+Arrows+C}] &g=&i=>
]

I did not include the backslash because I decided not to mess with the
choice of ASCII operators, however I do support making backslash an
operator. I am not sure about currency symbols.

Nevin

On Sun, Feb 5, 2017 at 1:20 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:

on Sun Feb 05 2017, Nicolas Fezans <swift-evolution@swift.org> wrote:

> Dear all,
>
> This is a rather simple proposal to add '\' (backslash character) as a
> valid operator-head in the swift grammar.
>
> One argument for it, is that there exist a backslash operator in the
> MATLAB/Scilab/Octave languages. In this languages A\B solves the linear
> system A*X = B for X (or the least square problem associated to it if the
> system of equations is overdetermined). I am doing some numerical
> computation in Swift and it would be nice to be able to declare the same
> operator name for this functionality.
>
> I might have missed some arguments for not adding them, but I seems to me
> that until now the \ character is only used inside of string literals. If
> that is the case, both uses should never generate a conflict or be
> ambiguous, isn't it? (String literals keep their interpretation of \ and
\
> used otherwise within the swift code will be interpreted as an operator
or
> as the beginning of an operator)
>
> I am curious to see what will be the feedback on this.

+1 if it doesn't clash with the grammar.

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

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


(Derrick Ho) #11

I have found it strange that operator characters are the only ones that may
be used as operators. Sometimes Characters that look like operators are not.

Why does there need to be a divide?

Why can't an arbitrary set of characters become operator-ized?

For example some people would like "and" to become a binary operator and
use it instead of "&&"

If we had the ability to define an operator out of any set of characters I
think it would make the swift language a lot better.

Is there a technical reason why?

···

On Tue, Feb 7, 2017 at 2:36 AM David Hart via swift-evolution < swift-evolution@swift.org> wrote:

And the overjoyed operator: \o/

On 7 Feb 2017, at 08:04, Slava Pestov via swift-evolution < > swift-evolution@swift.org> wrote:

I really have nothing to add to this discussion, except for this fun fact:
apparently, the backslash was added to ASCII so you could write /\ and \/
operators: http://www.bobbemer.com/BACSLASH.HTM

Slava

On Feb 5, 2017, at 7:29 AM, Nicolas Fezans via swift-evolution < > swift-evolution@swift.org> wrote:

Dear all,

This is a rather simple proposal to add '\' (backslash character) as a
valid operator-head in the swift grammar.

One argument for it, is that there exist a backslash operator in the
MATLAB/Scilab/Octave languages. In this languages A\B solves the linear
system A*X = B for X (or the least square problem associated to it if the
system of equations is overdetermined). I am doing some numerical
computation in Swift and it would be nice to be able to declare the same
operator name for this functionality.

I might have missed some arguments for not adding them, but I seems to me
that until now the \ character is only used inside of string literals. If
that is the case, both uses should never generate a conflict or be
ambiguous, isn't it? (String literals keep their interpretation of \ and \
used otherwise within the swift code will be interpreted as an operator or
as the beginning of an operator)

I am curious to see what will be the feedback on this.

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


#12

Although there was, as you say, some push-back against revamping our set of
operator characters, there was also substantial push-forward. Many people
want to resolve the problematic situation we currently have regarding the
designation of operators and identifiers.

And indeed, cutting back to ASCII-only operators would have been an
abominable choice. However waiting for the Unicode Consortium to draft
guidelines for operator characters means prolonging our existing
predicament. Additionally, in the discussion last fall it was mentioned
that Unicode personnel are aware of what we are doing with Swift operators,
and that our decisions may help to inform their classification of operator
characters:

That's a feasible way to go, but keep in mind that the UAX31 changes are
being co-designed with and informed by the current discussion. There are a
bunch of things that have come up here that will allow UAX31 to side-step
some "might have happened" mistakes, so this discussion has been very
useful.

The Swift community can and should make its own decision about whether to
remain engaged. The risk of disengagement is that messy compatibility
issues will probably have to be faced later that we can easily head-off now.

Given all these considerations, I think the principled approach is for us
to move forward with a 3-part categorization of characters into operators,
identifiers, and unspecified (to be determined). That way we need not
harangue ourselves over every controversial glyph, and may instead quickly
determine those characters which should definitely be operators and those
which should definitely be identifiers, while saving the difficult
decisions until such time as Unicode produces recommendations and/or we
decide to undertake a more comprehensive review.

Nevin

···

On Fri, Oct 21, 2016 at 5:38 PM, Jonathan S. Shapiro <jonathan.s.shapiro@ gmail.com> wrote:

On Sun, Feb 5, 2017 at 8:29 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

IIRC, where we left the discussion last time was that there was work not
yet complete within Unicode on delineating identifier and operator
characters. As there was broad agreement to align identifier characters
with Unicode standards, and since the strict separation between identifiers
and operators means that no character should belong to both, there was
hesitation to declare an operator what Unicode may later deem to be an
identifier.

There was strenuous objection to temporarily cutting back operators to the
ASCII range until Unicode completes its work, but also pushback in going
character-by-character above the ASCII range.

In any case, \ seems perfectly reasonable as an additional operator
character that doesn't have to wait for Unicode.

On Sun, Feb 5, 2017 at 19:02 T.J. Usiyan via swift-evolution < > swift-evolution@swift.org> wrote:

+1 from me.

I hope that operators get more work soon, especially with regard to math.

On Sun, Feb 5, 2017 at 5:09 PM, Nevin Brackett-Rozinsky via >> swift-evolution <swift-evolution@swift.org> wrote:

+1 as well. I also support adding these four symbols: ⅀ ؆ ؇ ⅋ as
operators.

There was substantial discussion last fall about revamping operators in
Swift, with the primary goal of removing characters that should not be in
the set. I went through the Unicode tables and compiled a list of 1,020
characters that I think definitely should be operators [list of operator
characters
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[[%3ASm%3A] -\p{Block%3DSuperscripts+And+Subscripts} -\p{Block%3DMiscellaneous+Technical} -\p{Block%3DGeometric+Shapes} -\p{Block%3DMiscellaneous+Symbols} -\p{Block%3DAlphabetic+Presentation+Forms} -\p{Block%3DSmall+Form+Variants} -\p{Block%3DHalfwidth+And+Fullwidth+Forms} -\p{Block%3DMathematical+Alphanumeric+Symbols} -\p{Block%3DArabic+Mathematical+Alphabetic+Symbols} -\p{subhead%3DVariant+letterforms+and+symbols} -\p{subhead%3DLetterlike+symbol} \p{Block%3DArrows} [%2F+%3D+\-+%2B+!+*+%+<+>+\%26+|+\^+~+%3F] [¡+¢+£+¤+¥+¦+§+©+«+¬+®+°+±+¶+»+¿]+-+[¢+£+¤+¥+©+®] \p{subhead%3DGeneral+punctuation}+-+[U%2B203F+U%2B2040+U%2B2045+U%2B2046+U%2B2054] \p{subhead%3DDouble+punctuation+for+vertical+text} \p{subhead%3DArchaic+punctuation}+-+[U%2B2E31+U%2B2E33+U%2B2E34+U%2B2E3F] U%2B214B]&g=&i=>
]

The effect of that would be to make 1,628 characters no longer usable as
operators [list of non-operator characters
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[%2F+%3D+\-+%2B+!++%25+%3C+%3E+%5C%26+%7C+%5C%5E+~+%3F%0D%0AU%2B00A1±+U%2B00A7%0D%0AU%2B00A9+U%2B00AB+U%2B00AC+U%2B00AE%0D%0AU%2B00B0±+U%2B00B1%0D%0AU%2B00B6+U%2B00BB+U%2B00BF+U%2B00D7+U%2B00F7%0D%0AU%2B2016±+U%2B2017%0D%0AU%2B2020±+U%2B2027%0D%0AU%2B2030±+U%2B203E%0D%0AU%2B2041±+U%2B2053%0D%0AU%2B2055±+U%2B205E%0D%0AU%2B2190±+U%2B23FF%0D%0AU%2B2500±+U%2B2775%0D%0AU%2B2794±+U%2B2BFF%0D%0AU%2B2E00±+U%2B2E7F%0D%0AU%2B3001±+U%2B3003%0D%0AU%2B3008±+U%2B3030%5D%0D%0A%0D%0A-%5B%5B%3ASm%3A%5D%0D%0A-%5Cp%7BBlock%3DSuperscripts+And+Subscripts%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Technical%7D%0D%0A-%5Cp%7BBlock%3DGeometric+Shapes%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Symbols%7D%0D%0A-%5Cp%7BBlock%3DAlphabetic+Presentation+Forms%7D%0D%0A-%5Cp%7BBlock%3DSmall+Form+Variants%7D%0D%0A-%5Cp%7BBlock%3DHalfwidth+And+Fullwidth+Forms%7D%0D%0A-%5Cp%7BBlock%3DMathematical+Alphanumeric+Symbols%7D%0D%0A-%5Cp%7BBlock%3DArabic+Mathematical+Alphabetic+Symbols%7D%0D%0A-%5Cp%7Bsubhead%3DVariant+letterforms+and+symbols%7D%0D%0A-%5Cp%7Bsubhead%3DLetterlike+symbol%7D%0D%0A%5Cp%7BBlock%3DArrows%7D%0D%0A%5B%2F+%3D+%5C-+%2B+%21++%25+%3C+%3E+%5C%26+%7C+%5C%5E+~+%3F%5D%0D%0A%5B%C2%A1+%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A6+%C2%A7+%C2%A9+%C2%AB+%C2%AC+%C2%AE+%C2%B0+%C2%B1+%C2%B6+%C2%BB+%C2%BF%5D±+%5B%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A9+%C2%AE%5D%0D%0A%5Cp%7Bsubhead%3DGeneral+punctuation%7D±+%5BU%2B203F+U%2B2040+U%2B2045+U%2B2046+U%2B2054%5D%0D%0A%5Cp%7Bsubhead%3DDouble+punctuation+for+vertical+text%7D%0D%0A%5Cp%7Bsubhead%3DArchaic+punctuation%7D±+%5BU%2B2E31+U%2B2E33+U%2B2E34+U%2B2E3F%5D%0D%0AU%2B214B%5D&g=&i=>
]

However, my strategy was to be conservative in accepting operators. There
are several Unicode blocks which contain some additional characters which
we may want to have as operators [list of characters in those blocks
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[\p{Block%3DMiscellaneous+Technical} \p{Block%3DOptical+Character+Recognition} \p{Block%3DBox+Drawing} \p{Block%3DBlock+Elements} \p{Block%3DGeometric+Shapes} \p{Block%3DMiscellaneous+Symbols} \p{Block%3DDingbats} \p{Block%3DBraille} \p{Block%3DMiscellaneous+Symbols+And+Arrows} \p{Block%3DYijing+Hexagram+Symbols} \p{Block%3DMusical+Symbols} \p{Block%3DAncient+Greek+Musical+Notation} \p{Block%3DTai+Xuan+Jing+Symbols} \p{Block%3DMahjong+Tiles} \p{Block%3DDomino+Tiles} \p{Block%3DPlaying+Cards} \p{Block%3DOrnamental+Dingbats} \p{Block%3DAlchemical+Symbols} \p{Block%3DGeometric+Shapes+Extended} \p{Block%3DSupplemental+Arrows+C}] &g=&i=>
]

I did not include the backslash because I decided not to mess with the
choice of ASCII operators, however I do support making backslash an
operator. I am not sure about currency symbols.

Nevin

On Sun, Feb 5, 2017 at 1:20 PM, Dave Abrahams via swift-evolution < >> swift-evolution@swift.org> wrote:

on Sun Feb 05 2017, Nicolas Fezans <swift-evolution@swift.org> wrote:

> Dear all,
>
> This is a rather simple proposal to add '\' (backslash character) as a
> valid operator-head in the swift grammar.
>
> One argument for it, is that there exist a backslash operator in the
> MATLAB/Scilab/Octave languages. In this languages A\B solves the linear
> system A*X = B for X (or the least square problem associated to it if
the
> system of equations is overdetermined). I am doing some numerical
> computation in Swift and it would be nice to be able to declare the same
> operator name for this functionality.
>
> I might have missed some arguments for not adding them, but I seems to
me
> that until now the \ character is only used inside of string literals.
If
> that is the case, both uses should never generate a conflict or be
> ambiguous, isn't it? (String literals keep their interpretation of \
and \
> used otherwise within the swift code will be interpreted as an operator
or
> as the beginning of an operator)
>
> I am curious to see what will be the feedback on this.

+1 if it doesn't clash with the grammar.

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

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


(David Waite) #13

I have found it strange that operator characters are the only ones that may be used as operators. Sometimes Characters that look like operators are not.

Why does there need to be a divide?

My understanding -
1. lets the lexer determine if a value is meant to be an identifier or an operator
2. prevents code declaring operators which impact the identifier space
3.-allows identifiers, literals and operators to interact without whitespace.

For the first point, syntactically ‘cas and ra’ would not be understandable until the compiler has determined that ‘and’ can be an operator, by parsing the rest of the code, which may also not make syntactic sense until the parser has understood other operator declarations

For the second part, declaring ‘and’ as an operator in a dependent module could impact your app if you had a variable or method named ‘and’.

For the last point - if any character could be an operator, then “casandra" could either be an identifier, or two identifiers (‘cas’ and ‘ra’) being operated on by the ‘and' operator.

So we have a group of name starter characters and operator starter characters to tell when the lever is ending an identifier and beginning an operator or vice-versa, and the two groups have to be non-overlapping.

-DW

···

On Feb 7, 2017, at 7:23 AM, Derrick Ho via swift-evolution <swift-evolution@swift.org> wrote:

Why can't an arbitrary set of characters become operator-ized?

For example some people would like "and" to become a binary operator and use it instead of "&&"

If we had the ability to define an operator out of any set of characters I think it would make the swift language a lot better.

Is there a technical reason why?


(Nicolas Fezans) #14

As long as you don't impose to have at list a space between operators and
identifiers you need to be able to split something like

a+b into an identifer called "a" followed by an operator "+" itself
followed by an identifier "b"

In principle we could think of using a way to delimiter an operator name we
could have very expressive operator name. Imagine for instance using
\(relativelyFreeOperatorName) outside a string literal defined as a valid
operator, then you could write

a\(relativelyFreeOperatorName)b

without any problem. This is actually quite appealing to me, knowing that
at some point, if the operator name becomes very long it seems relatively
pointless to me to define it as an operator and not simply as a function.

Nicolas

···

On Tue, Feb 7, 2017 at 3:23 PM, Derrick Ho via swift-evolution < swift-evolution@swift.org> wrote:

I have found it strange that operator characters are the only ones that
may be used as operators. Sometimes Characters that look like operators are
not.

Why does there need to be a divide?

Why can't an arbitrary set of characters become operator-ized?

For example some people would like "and" to become a binary operator and
use it instead of "&&"

If we had the ability to define an operator out of any set of characters I
think it would make the swift language a lot better.

Is there a technical reason why?

On Tue, Feb 7, 2017 at 2:36 AM David Hart via swift-evolution < > swift-evolution@swift.org> wrote:

And the overjoyed operator: \o/

On 7 Feb 2017, at 08:04, Slava Pestov via swift-evolution < >> swift-evolution@swift.org> wrote:

I really have nothing to add to this discussion, except for this fun
fact: apparently, the backslash was added to ASCII so you could write /\
and \/ operators: http://www.bobbemer.com/BACSLASH.HTM

Slava

On Feb 5, 2017, at 7:29 AM, Nicolas Fezans via swift-evolution < >> swift-evolution@swift.org> wrote:

Dear all,

This is a rather simple proposal to add '\' (backslash character) as a
valid operator-head in the swift grammar.

One argument for it, is that there exist a backslash operator in the
MATLAB/Scilab/Octave languages. In this languages A\B solves the linear
system A*X = B for X (or the least square problem associated to it if the
system of equations is overdetermined). I am doing some numerical
computation in Swift and it would be nice to be able to declare the same
operator name for this functionality.

I might have missed some arguments for not adding them, but I seems to me
that until now the \ character is only used inside of string literals. If
that is the case, both uses should never generate a conflict or be
ambiguous, isn't it? (String literals keep their interpretation of \ and \
used otherwise within the swift code will be interpreted as an operator or
as the beginning of an operator)

I am curious to see what will be the feedback on this.

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


(Xiaodi Wu) #15

Indeed, I'd be thrilled to revise and reintroduce a proposal to update
identifier and operator characters, if co-authors of that proposal are OK
with it. Agree entirely with the principle you enunciate; that is exactly
how we tried to approach it previously. I take it that you agree that a
comprehensive revision of identifier characters cannot happen without
thinking about operator characters, and vice versa, and I believe we came
to that conclusion as well.

Two difficulties arose. Jonathan Shapiro indicated that the Unicode
approach would invariably be to specify which characters are valid
identifiers, etc. not by code points or planes but by "categories," for
which there are none for operators but also for which there are problematic
ones for emoji (the numerals 0-9 belong to the emoji category, for
instance; there is another emoji_presentation category which has its own
tricks). Therefore, we considered that the most conservative way to
classify "definite operators," "definite identifiers," and everything else
was to leave emoji out (UAX31 does not include them as identifier
characters) and to roll back operator characters to the ASCII range.
However, both temporary measures were soundly rejected.

There are a number of security issues to be ironed out with respect to
emoji. For instance, emoji modifiers such as skin tones and genders allow
different identifiers to be made that are visually identical or nearly so.
(And yes, I'm aware that you or I could come up with an ad-hoc solution to
this particular problem with emoji, but the issue is identifying all such
relevant problems and coming up with solutions that jibe with future
Unicode solutions to the same problems.) It would have been nice to leave
this out entirely for now until further guidance from Unicode experts, but
the community made it clear that emoji were a sine qua non.

Likewise, every discussion on operator characters thus far has devolved
into a series of replies nominating specific characters for inclusion. I
continue to believe a character-by-character debate on this mailing list
would be exceptionally poor form. My point in replying to this thread is
only that we don't need to get into any of this (Unicode operators,
canonicalization forms, emoji, etc.--much as I would love to) in order to
consider the isolated addition of an ASCII-range operator \. That idea
seems very reasonable, independently useful, and limited in scope.

···

On Mon, Feb 6, 2017 at 15:28 Nevin Brackett-Rozinsky via swift-evolution < swift-evolution@swift.org> wrote:

Although there was, as you say, some push-back against revamping our set
of operator characters, there was also substantial push-forward. Many
people want to resolve the problematic situation we currently have
regarding the designation of operators and identifiers.

And indeed, cutting back to ASCII-only operators would have been an
abominable choice. However waiting for the Unicode Consortium to draft
guidelines for operator characters means prolonging our existing
predicament. Additionally, in the discussion last fall it was mentioned
that Unicode personnel are aware of what we are doing with Swift operators,
and that our decisions may help to inform their classification of operator
characters:

On Fri, Oct 21, 2016 at 5:38 PM, Jonathan S. Shapiro < > jonathan.s.shapiro@gmail.com> wrote:

That's a feasible way to go, but keep in mind that the UAX31 changes are
being co-designed with and informed by the current discussion. There are a
bunch of things that have come up here that will allow UAX31 to side-step
some "might have happened" mistakes, so this discussion has been very
useful.

The Swift community can and should make its own decision about whether to
remain engaged. The risk of disengagement is that messy compatibility
issues will probably have to be faced later that we can easily head-off now.

Given all these considerations, I think the principled approach is for us
to move forward with a 3-part categorization of characters into operators,
identifiers, and unspecified (to be determined). That way we need not
harangue ourselves over every controversial glyph, and may instead quickly
determine those characters which should definitely be operators and those
which should definitely be identifiers, while saving the difficult
decisions until such time as Unicode produces recommendations and/or we
decide to undertake a more comprehensive review.

Nevin

On Sun, Feb 5, 2017 at 8:29 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

IIRC, where we left the discussion last time was that there was work not
yet complete within Unicode on delineating identifier and operator
characters. As there was broad agreement to align identifier characters
with Unicode standards, and since the strict separation between identifiers
and operators means that no character should belong to both, there was
hesitation to declare an operator what Unicode may later deem to be an
identifier.

There was strenuous objection to temporarily cutting back operators to the
ASCII range until Unicode completes its work, but also pushback in going
character-by-character above the ASCII range.

In any case, \ seems perfectly reasonable as an additional operator
character that doesn't have to wait for Unicode.

On Sun, Feb 5, 2017 at 19:02 T.J. Usiyan via swift-evolution < > swift-evolution@swift.org> wrote:

+1 from me.

I hope that operators get more work soon, especially with regard to math.

On Sun, Feb 5, 2017 at 5:09 PM, Nevin Brackett-Rozinsky via > swift-evolution <swift-evolution@swift.org> wrote:

+1 as well. I also support adding these four symbols: ⅀ ؆ ؇ ⅋ as
operators.

There was substantial discussion last fall about revamping operators in
Swift, with the primary goal of removing characters that should not be in
the set. I went through the Unicode tables and compiled a list of 1,020
characters that I think definitely should be operators [list of operator
characters
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[[%3ASm%3A] -\p{Block%3DSuperscripts+And+Subscripts} -\p{Block%3DMiscellaneous+Technical} -\p{Block%3DGeometric+Shapes} -\p{Block%3DMiscellaneous+Symbols} -\p{Block%3DAlphabetic+Presentation+Forms} -\p{Block%3DSmall+Form+Variants} -\p{Block%3DHalfwidth+And+Fullwidth+Forms} -\p{Block%3DMathematical+Alphanumeric+Symbols} -\p{Block%3DArabic+Mathematical+Alphabetic+Symbols} -\p{subhead%3DVariant+letterforms+and+symbols} -\p{subhead%3DLetterlike+symbol} \p{Block%3DArrows} [%2F+%3D+\-+%2B+!+*+%+<+>+\%26+|+\^+~+%3F] [¡+¢+£+¤+¥+¦+§+©+«+¬+®+°+±+¶+»+¿]+-+[¢+£+¤+¥+©+®] \p{subhead%3DGeneral+punctuation}+-+[U%2B203F+U%2B2040+U%2B2045+U%2B2046+U%2B2054] \p{subhead%3DDouble+punctuation+for+vertical+text} \p{subhead%3DArchaic+punctuation}+-+[U%2B2E31+U%2B2E33+U%2B2E34+U%2B2E3F] U%2B214B]&g=&i=>
]

The effect of that would be to make 1,628 characters no longer usable as
operators [list of non-operator characters
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[%2F+%3D+\-+%2B+!++%25+%3C+%3E+%5C%26+%7C+%5C%5E+~+%3F%0D%0AU%2B00A1±+U%2B00A7%0D%0AU%2B00A9+U%2B00AB+U%2B00AC+U%2B00AE%0D%0AU%2B00B0±+U%2B00B1%0D%0AU%2B00B6+U%2B00BB+U%2B00BF+U%2B00D7+U%2B00F7%0D%0AU%2B2016±+U%2B2017%0D%0AU%2B2020±+U%2B2027%0D%0AU%2B2030±+U%2B203E%0D%0AU%2B2041±+U%2B2053%0D%0AU%2B2055±+U%2B205E%0D%0AU%2B2190±+U%2B23FF%0D%0AU%2B2500±+U%2B2775%0D%0AU%2B2794±+U%2B2BFF%0D%0AU%2B2E00±+U%2B2E7F%0D%0AU%2B3001±+U%2B3003%0D%0AU%2B3008±+U%2B3030%5D%0D%0A%0D%0A-%5B%5B%3ASm%3A%5D%0D%0A-%5Cp%7BBlock%3DSuperscripts+And+Subscripts%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Technical%7D%0D%0A-%5Cp%7BBlock%3DGeometric+Shapes%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Symbols%7D%0D%0A-%5Cp%7BBlock%3DAlphabetic+Presentation+Forms%7D%0D%0A-%5Cp%7BBlock%3DSmall+Form+Variants%7D%0D%0A-%5Cp%7BBlock%3DHalfwidth+And+Fullwidth+Forms%7D%0D%0A-%5Cp%7BBlock%3DMathematical+Alphanumeric+Symbols%7D%0D%0A-%5Cp%7BBlock%3DArabic+Mathematical+Alphabetic+Symbols%7D%0D%0A-%5Cp%7Bsubhead%3DVariant+letterforms+and+symbols%7D%0D%0A-%5Cp%7Bsubhead%3DLetterlike+symbol%7D%0D%0A%5Cp%7BBlock%3DArrows%7D%0D%0A%5B%2F+%3D+%5C-+%2B+%21++%25+%3C+%3E+%5C%26+%7C+%5C%5E+~+%3F%5D%0D%0A%5B%C2%A1+%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A6+%C2%A7+%C2%A9+%C2%AB+%C2%AC+%C2%AE+%C2%B0+%C2%B1+%C2%B6+%C2%BB+%C2%BF%5D±+%5B%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A9+%C2%AE%5D%0D%0A%5Cp%7Bsubhead%3DGeneral+punctuation%7D±+%5BU%2B203F+U%2B2040+U%2B2045+U%2B2046+U%2B2054%5D%0D%0A%5Cp%7Bsubhead%3DDouble+punctuation+for+vertical+text%7D%0D%0A%5Cp%7Bsubhead%3DArchaic+punctuation%7D±+%5BU%2B2E31+U%2B2E33+U%2B2E34+U%2B2E3F%5D%0D%0AU%2B214B%5D&g=&i=>
]

However, my strategy was to be conservative in accepting operators. There
are several Unicode blocks which contain some additional characters which
we may want to have as operators [list of characters in those blocks
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[\p{Block%3DMiscellaneous+Technical} \p{Block%3DOptical+Character+Recognition} \p{Block%3DBox+Drawing} \p{Block%3DBlock+Elements} \p{Block%3DGeometric+Shapes} \p{Block%3DMiscellaneous+Symbols} \p{Block%3DDingbats} \p{Block%3DBraille} \p{Block%3DMiscellaneous+Symbols+And+Arrows} \p{Block%3DYijing+Hexagram+Symbols} \p{Block%3DMusical+Symbols} \p{Block%3DAncient+Greek+Musical+Notation} \p{Block%3DTai+Xuan+Jing+Symbols} \p{Block%3DMahjong+Tiles} \p{Block%3DDomino+Tiles} \p{Block%3DPlaying+Cards} \p{Block%3DOrnamental+Dingbats} \p{Block%3DAlchemical+Symbols} \p{Block%3DGeometric+Shapes+Extended} \p{Block%3DSupplemental+Arrows+C}] &g=&i=>
]

I did not include the backslash because I decided not to mess with the
choice of ASCII operators, however I do support making backslash an
operator. I am not sure about currency symbols.

Nevin

On Sun, Feb 5, 2017 at 1:20 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:

on Sun Feb 05 2017, Nicolas Fezans <swift-evolution@swift.org> wrote:

> Dear all,
>
> This is a rather simple proposal to add '\' (backslash character) as a
> valid operator-head in the swift grammar.
>
> One argument for it, is that there exist a backslash operator in the
> MATLAB/Scilab/Octave languages. In this languages A\B solves the linear
> system A*X = B for X (or the least square problem associated to it if the
> system of equations is overdetermined). I am doing some numerical
> computation in Swift and it would be nice to be able to declare the same
> operator name for this functionality.
>
> I might have missed some arguments for not adding them, but I seems to me
> that until now the \ character is only used inside of string literals. If
> that is the case, both uses should never generate a conflict or be
> ambiguous, isn't it? (String literals keep their interpretation of \ and
\
> used otherwise within the swift code will be interpreted as an operator
or
> as the beginning of an operator)
>
> I am curious to see what will be the feedback on this.

+1 if it doesn't clash with the grammar.

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

_______________________________________________
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


(Xiaodi Wu) #16

Given that the definition of operator characters in Swift is “part of
Swift”, it follows that any change to that set will go through the Swift
Evolution process, which includes discussion on this list. I do not see a
reasonable way to skip that, nor would I consider it desirable to do so.
Discussing on this list which characters should be operators in Swift is
*prima facie* a necessary part of changing them.

In light of the fact that our current operator-character situation needs
to be fixed—meaning we will have to decide which characters should and
should not be allowed in operators—and seeing as any proposal to solve the
problem will be discussed on this list, the natural conclusion is that
discussing which characters should be operators is *exactly* what we ought
to do.

Moreover, we are trying to decide which operators are right for *Swift*,
thus our goals include expressivity, usefulness, and enjoyability. Our
goals do *not* include being maximally conservative, and indeed I view
parsimony in operator-character availability as undesirable.

We should aim to choose the *right* set of operator characters, for some
Swifty and opinionated value of “right”. If the recommendations that
Unicode settles on strike us as right for Swift, that is great. But those
recommendations do not exist yet, and so far it sounds like they could well
be defined in a way which is *not* right for Swift.

Perhaps Unicode will add a new category for operators, and they will go
character-by-character to put certain glyphs in it. But if they don’t, then
as you say the existing categories are not sufficient for Swift’s purposes,
so their recommendations will not solve our problem. And if they do, we
still would need to verify that their decision matches our use-case.

The past proposal to gut non-ASCII operators from Swift was rightly
blocked, for it would have damaged the language. My follow-up with a list
of 1,020 characters to use as operators has not seen much discussion. If
there were any controversial characters in it or omissions from it, I hope
someone would raise an objection.

In any case, I think that discussing which characters are right for Swift
operators is an entirely proper and expected use of this mailing list, and
I suggest we do so during the Swift 4 timeframe because it affects source
compatibility.

You misunderstand my drift. Of course any such change to Swift would have
to go through this list, and of course that involves asking which
characters are right for Swift operators. The question is _how_ to
undertake a fruitful discussion.

Consider this: that part of our previous draft which concerned adopting
UAX#31 received immediate and almost universal consensus. One technical
report has made it possible to adopt a cogent set of some 100,000-odd
characters for identifiers *without* analyzing each one, with the added
benefit that Swift would be able to parallel the evolution of Unicode in
that respect as the years go on. That analysis involved, exactly as you
say, asking exactly which characters make sense for Swift identifiers, but
did so by means of overarching principles (for example, should aspirational
scripts be included?).

By comparison, that part of the previous draft which concerned matters not
yet settled by Unicode experts prompted vehement disagreement, with great
debate on the minutiae of individual codepoints that never reached
consensus. I too have made a list of 500-1000 operator characters. Several
versions in fact. So did other authors of the previous draft. Some of us
made character-by-character lists. Some also made block-by-block lists. We
carefully considered which operators might overlap with emojis, and which
were confusables, and whether operators require different Unicode
normalization from identifiers. We debated questions such as whether tiny
and miny were mathematical operators or something else. Make no mistake, we
reached no ultimate consensus on a lot of these questions even amongst the
authors.

I have held off on re-introducing this proposal in part because I'm
seriously concerned that, without a better method, such an exercise is
exceedingly poor form on such a high-traffic list. After all, we don't go
line-by-line through draft implementations of proposed features on this
list. We need to be able to articulate useful principles by which
characters outside the ASCII range will be classified as operators;
Jonathan Shapiro has indicated that not even Unicode will proceed with an
ad-hoc character-by-character analysis. If we can come up with overarching
principles that are workable, then it is plausible that Unicode will follow
our lead. So yes, I agree with you absolutely, discussing which characters
are right for Swift operators is an entirely proper and expected use of
this mailing list. Now, _how_ to discuss it? I feel very strongly the
answer is not by scrutiny of a list of codepoints.

In any case, again we've gone far afield. I'm supportive of adding \ as an
operator. That is a standalone proposal with its own merits; would love to
see that proposed and considered on its own.

Nevin

···

On Mon, Feb 6, 2017 at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution@swift.org> wrote:

On Mon, Feb 6, 2017 at 7:05 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

Indeed, I'd be thrilled to revise and reintroduce a proposal to update
identifier and operator characters, if co-authors of that proposal are OK
with it. Agree entirely with the principle you enunciate; that is exactly
how we tried to approach it previously. I take it that you agree that a
comprehensive revision of identifier characters cannot happen without
thinking about operator characters, and vice versa, and I believe we came
to that conclusion as well.

Two difficulties arose. Jonathan Shapiro indicated that the Unicode
approach would invariably be to specify which characters are valid
identifiers, etc. not by code points or planes but by "categories," for
which there are none for operators but also for which there are problematic
ones for emoji (the numerals 0-9 belong to the emoji category, for
instance; there is another emoji_presentation category which has its own
tricks). Therefore, we considered that the most conservative way to
classify "definite operators," "definite identifiers," and everything else
was to leave emoji out (UAX31 does not include them as identifier
characters) and to roll back operator characters to the ASCII range.
However, both temporary measures were soundly rejected.

There are a number of security issues to be ironed out with respect to
emoji. For instance, emoji modifiers such as skin tones and genders allow
different identifiers to be made that are visually identical or nearly so.
(And yes, I'm aware that you or I could come up with an ad-hoc solution to
this particular problem with emoji, but the issue is identifying all such
relevant problems and coming up with solutions that jibe with future
Unicode solutions to the same problems.) It would have been nice to leave
this out entirely for now until further guidance from Unicode experts, but
the community made it clear that emoji were a sine qua non.

Likewise, every discussion on operator characters thus far has devolved
into a series of replies nominating specific characters for inclusion. I
continue to believe a character-by-character debate on this mailing list
would be exceptionally poor form. My point in replying to this thread is
only that we don't need to get into any of this (Unicode operators,
canonicalization forms, emoji, etc.--much as I would love to) in order to
consider the isolated addition of an ASCII-range operator \. That idea
seems very reasonable, independently useful, and limited in scope.

On Mon, Feb 6, 2017 at 15:28 Nevin Brackett-Rozinsky via swift-evolution < >> swift-evolution@swift.org> wrote:

Although there was, as you say, some push-back against revamping our set
of operator characters, there was also substantial push-forward. Many
people want to resolve the problematic situation we currently have
regarding the designation of operators and identifiers.

And indeed, cutting back to ASCII-only operators would have been an
abominable choice. However waiting for the Unicode Consortium to draft
guidelines for operator characters means prolonging our existing
predicament. Additionally, in the discussion last fall it was mentioned
that Unicode personnel are aware of what we are doing with Swift operators,
and that our decisions may help to inform their classification of operator
characters:

On Fri, Oct 21, 2016 at 5:38 PM, Jonathan S. Shapiro < >>> jonathan.s.shapiro@gmail.com> wrote:

That's a feasible way to go, but keep in mind that the UAX31 changes are
being co-designed with and informed by the current discussion. There are a
bunch of things that have come up here that will allow UAX31 to side-step
some "might have happened" mistakes, so this discussion has been very
useful.

The Swift community can and should make its own decision about whether
to remain engaged. The risk of disengagement is that messy compatibility
issues will probably have to be faced later that we can easily head-off now.

Given all these considerations, I think the principled approach is for
us to move forward with a 3-part categorization of characters into
operators, identifiers, and unspecified (to be determined). That way we
need not harangue ourselves over every controversial glyph, and may instead
quickly determine those characters which should definitely be operators and
those which should definitely be identifiers, while saving the difficult
decisions until such time as Unicode produces recommendations and/or we
decide to undertake a more comprehensive review.

Nevin

On Sun, Feb 5, 2017 at 8:29 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

IIRC, where we left the discussion last time was that there was work not
yet complete within Unicode on delineating identifier and operator
characters. As there was broad agreement to align identifier characters
with Unicode standards, and since the strict separation between identifiers
and operators means that no character should belong to both, there was
hesitation to declare an operator what Unicode may later deem to be an
identifier.

There was strenuous objection to temporarily cutting back operators to
the ASCII range until Unicode completes its work, but also pushback in
going character-by-character above the ASCII range.

In any case, \ seems perfectly reasonable as an additional operator
character that doesn't have to wait for Unicode.

On Sun, Feb 5, 2017 at 19:02 T.J. Usiyan via swift-evolution < >>> swift-evolution@swift.org> wrote:

+1 from me.

I hope that operators get more work soon, especially with regard to math.

On Sun, Feb 5, 2017 at 5:09 PM, Nevin Brackett-Rozinsky via >>> swift-evolution <swift-evolution@swift.org> wrote:

+1 as well. I also support adding these four symbols: ⅀ ؆ ؇ ⅋ as
operators.

There was substantial discussion last fall about revamping operators in
Swift, with the primary goal of removing characters that should not be in
the set. I went through the Unicode tables and compiled a list of 1,020
characters that I think definitely should be operators [list of
operator characters
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[[%3ASm%3A] -\p{Block%3DSuperscripts+And+Subscripts} -\p{Block%3DMiscellaneous+Technical} -\p{Block%3DGeometric+Shapes} -\p{Block%3DMiscellaneous+Symbols} -\p{Block%3DAlphabetic+Presentation+Forms} -\p{Block%3DSmall+Form+Variants} -\p{Block%3DHalfwidth+And+Fullwidth+Forms} -\p{Block%3DMathematical+Alphanumeric+Symbols} -\p{Block%3DArabic+Mathematical+Alphabetic+Symbols} -\p{subhead%3DVariant+letterforms+and+symbols} -\p{subhead%3DLetterlike+symbol} \p{Block%3DArrows} [%2F+%3D+\-+%2B+!+*+%+<+>+\%26+|+\^+~+%3F] [¡+¢+£+¤+¥+¦+§+©+«+¬+®+°+±+¶+»+¿]+-+[¢+£+¤+¥+©+®] \p{subhead%3DGeneral+punctuation}+-+[U%2B203F+U%2B2040+U%2B2045+U%2B2046+U%2B2054] \p{subhead%3DDouble+punctuation+for+vertical+text} \p{subhead%3DArchaic+punctuation}+-+[U%2B2E31+U%2B2E33+U%2B2E34+U%2B2E3F] U%2B214B]&g=&i=>
]

The effect of that would be to make 1,628 characters no longer usable as
operators [list of non-operator characters
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[%2F+%3D+\-+%2B+!++%25+%3C+%3E+%5C%26+%7C+%5C%5E+~+%3F%0D%0AU%2B00A1±+U%2B00A7%0D%0AU%2B00A9+U%2B00AB+U%2B00AC+U%2B00AE%0D%0AU%2B00B0±+U%2B00B1%0D%0AU%2B00B6+U%2B00BB+U%2B00BF+U%2B00D7+U%2B00F7%0D%0AU%2B2016±+U%2B2017%0D%0AU%2B2020±+U%2B2027%0D%0AU%2B2030±+U%2B203E%0D%0AU%2B2041±+U%2B2053%0D%0AU%2B2055±+U%2B205E%0D%0AU%2B2190±+U%2B23FF%0D%0AU%2B2500±+U%2B2775%0D%0AU%2B2794±+U%2B2BFF%0D%0AU%2B2E00±+U%2B2E7F%0D%0AU%2B3001±+U%2B3003%0D%0AU%2B3008±+U%2B3030%5D%0D%0A%0D%0A-%5B%5B%3ASm%3A%5D%0D%0A-%5Cp%7BBlock%3DSuperscripts+And+Subscripts%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Technical%7D%0D%0A-%5Cp%7BBlock%3DGeometric+Shapes%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Symbols%7D%0D%0A-%5Cp%7BBlock%3DAlphabetic+Presentation+Forms%7D%0D%0A-%5Cp%7BBlock%3DSmall+Form+Variants%7D%0D%0A-%5Cp%7BBlock%3DHalfwidth+And+Fullwidth+Forms%7D%0D%0A-%5Cp%7BBlock%3DMathematical+Alphanumeric+Symbols%7D%0D%0A-%5Cp%7BBlock%3DArabic+Mathematical+Alphabetic+Symbols%7D%0D%0A-%5Cp%7Bsubhead%3DVariant+letterforms+and+symbols%7D%0D%0A-%5Cp%7Bsubhead%3DLetterlike+symbol%7D%0D%0A%5Cp%7BBlock%3DArrows%7D%0D%0A%5B%2F+%3D+%5C-+%2B+%21++%25+%3C+%3E+%5C%26+%7C+%5C%5E+~+%3F%5D%0D%0A%5B%C2%A1+%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A6+%C2%A7+%C2%A9+%C2%AB+%C2%AC+%C2%AE+%C2%B0+%C2%B1+%C2%B6+%C2%BB+%C2%BF%5D±+%5B%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A9+%C2%AE%5D%0D%0A%5Cp%7Bsubhead%3DGeneral+punctuation%7D±+%5BU%2B203F+U%2B2040+U%2B2045+U%2B2046+U%2B2054%5D%0D%0A%5Cp%7Bsubhead%3DDouble+punctuation+for+vertical+text%7D%0D%0A%5Cp%7Bsubhead%3DArchaic+punctuation%7D±+%5BU%2B2E31+U%2B2E33+U%2B2E34+U%2B2E3F%5D%0D%0AU%2B214B%5D&g=&i=>
]

However, my strategy was to be conservative in accepting operators.
There are several Unicode blocks which contain some additional characters
which we may want to have as operators [list of characters in those
blocks
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[\p{Block%3DMiscellaneous+Technical} \p{Block%3DOptical+Character+Recognition} \p{Block%3DBox+Drawing} \p{Block%3DBlock+Elements} \p{Block%3DGeometric+Shapes} \p{Block%3DMiscellaneous+Symbols} \p{Block%3DDingbats} \p{Block%3DBraille} \p{Block%3DMiscellaneous+Symbols+And+Arrows} \p{Block%3DYijing+Hexagram+Symbols} \p{Block%3DMusical+Symbols} \p{Block%3DAncient+Greek+Musical+Notation} \p{Block%3DTai+Xuan+Jing+Symbols} \p{Block%3DMahjong+Tiles} \p{Block%3DDomino+Tiles} \p{Block%3DPlaying+Cards} \p{Block%3DOrnamental+Dingbats} \p{Block%3DAlchemical+Symbols} \p{Block%3DGeometric+Shapes+Extended} \p{Block%3DSupplemental+Arrows+C}] &g=&i=>
]

I did not include the backslash because I decided not to mess with the
choice of ASCII operators, however I do support making backslash an
operator. I am not sure about currency symbols.

Nevin

On Sun, Feb 5, 2017 at 1:20 PM, Dave Abrahams via swift-evolution < >>> swift-evolution@swift.org> wrote:

on Sun Feb 05 2017, Nicolas Fezans <swift-evolution@swift.org> wrote:

> Dear all,
>
> This is a rather simple proposal to add '\' (backslash character) as a
> valid operator-head in the swift grammar.
>
> One argument for it, is that there exist a backslash operator in the
> MATLAB/Scilab/Octave languages. In this languages A\B solves the linear
> system A*X = B for X (or the least square problem associated to it if
the
> system of equations is overdetermined). I am doing some numerical
> computation in Swift and it would be nice to be able to declare the
same
> operator name for this functionality.
>
> I might have missed some arguments for not adding them, but I seems to
me
> that until now the \ character is only used inside of string literals.
If
> that is the case, both uses should never generate a conflict or be
> ambiguous, isn't it? (String literals keep their interpretation of \
and \
> used otherwise within the swift code will be interpreted as an
operator or
> as the beginning of an operator)
>
> I am curious to see what will be the feedback on this.

+1 if it doesn't clash with the grammar.

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

_______________________________________________
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


#17

Given that the definition of operator characters in Swift is “part of
Swift”, it follows that any change to that set will go through the Swift
Evolution process, which includes discussion on this list. I do not see a
reasonable way to skip that, nor would I consider it desirable to do so.
Discussing on this list which characters should be operators in Swift is
*prima facie* a necessary part of changing them.

In light of the fact that our current operator-character situation needs to
be fixed—meaning we will have to decide which characters should and should
not be allowed in operators—and seeing as any proposal to solve the problem
will be discussed on this list, the natural conclusion is that discussing
which characters should be operators is *exactly* what we ought to do.

Moreover, we are trying to decide which operators are right for *Swift*,
thus our goals include expressivity, usefulness, and enjoyability. Our
goals do *not* include being maximally conservative, and indeed I view
parsimony in operator-character availability as undesirable.

We should aim to choose the *right* set of operator characters, for some
Swifty and opinionated value of “right”. If the recommendations that
Unicode settles on strike us as right for Swift, that is great. But those
recommendations do not exist yet, and so far it sounds like they could well
be defined in a way which is *not* right for Swift.

Perhaps Unicode will add a new category for operators, and they will go
character-by-character to put certain glyphs in it. But if they don’t, then
as you say the existing categories are not sufficient for Swift’s purposes,
so their recommendations will not solve our problem. And if they do, we
still would need to verify that their decision matches our use-case.

The past proposal to gut non-ASCII operators from Swift was rightly
blocked, for it would have damaged the language. My follow-up with a list
of 1,020 characters to use as operators has not seen much discussion. If
there were any controversial characters in it or omissions from it, I hope
someone would raise an objection.

In any case, I think that discussing which characters are right for Swift
operators is an entirely proper and expected use of this mailing list, and
I suggest we do so during the Swift 4 timeframe because it affects source
compatibility.

Nevin

···

On Mon, Feb 6, 2017 at 7:05 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

Indeed, I'd be thrilled to revise and reintroduce a proposal to update
identifier and operator characters, if co-authors of that proposal are OK
with it. Agree entirely with the principle you enunciate; that is exactly
how we tried to approach it previously. I take it that you agree that a
comprehensive revision of identifier characters cannot happen without
thinking about operator characters, and vice versa, and I believe we came
to that conclusion as well.

Two difficulties arose. Jonathan Shapiro indicated that the Unicode
approach would invariably be to specify which characters are valid
identifiers, etc. not by code points or planes but by "categories," for
which there are none for operators but also for which there are problematic
ones for emoji (the numerals 0-9 belong to the emoji category, for
instance; there is another emoji_presentation category which has its own
tricks). Therefore, we considered that the most conservative way to
classify "definite operators," "definite identifiers," and everything else
was to leave emoji out (UAX31 does not include them as identifier
characters) and to roll back operator characters to the ASCII range.
However, both temporary measures were soundly rejected.

There are a number of security issues to be ironed out with respect to
emoji. For instance, emoji modifiers such as skin tones and genders allow
different identifiers to be made that are visually identical or nearly so.
(And yes, I'm aware that you or I could come up with an ad-hoc solution to
this particular problem with emoji, but the issue is identifying all such
relevant problems and coming up with solutions that jibe with future
Unicode solutions to the same problems.) It would have been nice to leave
this out entirely for now until further guidance from Unicode experts, but
the community made it clear that emoji were a sine qua non.

Likewise, every discussion on operator characters thus far has devolved
into a series of replies nominating specific characters for inclusion. I
continue to believe a character-by-character debate on this mailing list
would be exceptionally poor form. My point in replying to this thread is
only that we don't need to get into any of this (Unicode operators,
canonicalization forms, emoji, etc.--much as I would love to) in order to
consider the isolated addition of an ASCII-range operator \. That idea
seems very reasonable, independently useful, and limited in scope.

On Mon, Feb 6, 2017 at 15:28 Nevin Brackett-Rozinsky via swift-evolution < > swift-evolution@swift.org> wrote:

Although there was, as you say, some push-back against revamping our set
of operator characters, there was also substantial push-forward. Many
people want to resolve the problematic situation we currently have
regarding the designation of operators and identifiers.

And indeed, cutting back to ASCII-only operators would have been an
abominable choice. However waiting for the Unicode Consortium to draft
guidelines for operator characters means prolonging our existing
predicament. Additionally, in the discussion last fall it was mentioned
that Unicode personnel are aware of what we are doing with Swift operators,
and that our decisions may help to inform their classification of operator
characters:

On Fri, Oct 21, 2016 at 5:38 PM, Jonathan S. Shapiro <jonathan.s.shapiro@ >> gmail.com> wrote:

That's a feasible way to go, but keep in mind that the UAX31 changes are
being co-designed with and informed by the current discussion. There are a
bunch of things that have come up here that will allow UAX31 to side-step
some "might have happened" mistakes, so this discussion has been very
useful.

The Swift community can and should make its own decision about whether to
remain engaged. The risk of disengagement is that messy compatibility
issues will probably have to be faced later that we can easily head-off now.

Given all these considerations, I think the principled approach is for us
to move forward with a 3-part categorization of characters into operators,
identifiers, and unspecified (to be determined). That way we need not
harangue ourselves over every controversial glyph, and may instead quickly
determine those characters which should definitely be operators and those
which should definitely be identifiers, while saving the difficult
decisions until such time as Unicode produces recommendations and/or we
decide to undertake a more comprehensive review.

Nevin

On Sun, Feb 5, 2017 at 8:29 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

IIRC, where we left the discussion last time was that there was work not
yet complete within Unicode on delineating identifier and operator
characters. As there was broad agreement to align identifier characters
with Unicode standards, and since the strict separation between identifiers
and operators means that no character should belong to both, there was
hesitation to declare an operator what Unicode may later deem to be an
identifier.

There was strenuous objection to temporarily cutting back operators to
the ASCII range until Unicode completes its work, but also pushback in
going character-by-character above the ASCII range.

In any case, \ seems perfectly reasonable as an additional operator
character that doesn't have to wait for Unicode.

On Sun, Feb 5, 2017 at 19:02 T.J. Usiyan via swift-evolution < >> swift-evolution@swift.org> wrote:

+1 from me.

I hope that operators get more work soon, especially with regard to math.

On Sun, Feb 5, 2017 at 5:09 PM, Nevin Brackett-Rozinsky via >> swift-evolution <swift-evolution@swift.org> wrote:

+1 as well. I also support adding these four symbols: ⅀ ؆ ؇ ⅋ as
operators.

There was substantial discussion last fall about revamping operators in
Swift, with the primary goal of removing characters that should not be in
the set. I went through the Unicode tables and compiled a list of 1,020
characters that I think definitely should be operators [list of operator
characters
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[[%3ASm%3A] -\p{Block%3DSuperscripts+And+Subscripts} -\p{Block%3DMiscellaneous+Technical} -\p{Block%3DGeometric+Shapes} -\p{Block%3DMiscellaneous+Symbols} -\p{Block%3DAlphabetic+Presentation+Forms} -\p{Block%3DSmall+Form+Variants} -\p{Block%3DHalfwidth+And+Fullwidth+Forms} -\p{Block%3DMathematical+Alphanumeric+Symbols} -\p{Block%3DArabic+Mathematical+Alphabetic+Symbols} -\p{subhead%3DVariant+letterforms+and+symbols} -\p{subhead%3DLetterlike+symbol} \p{Block%3DArrows} [%2F+%3D+\-+%2B+!+*+%+<+>+\%26+|+\^+~+%3F] [¡+¢+£+¤+¥+¦+§+©+«+¬+®+°+±+¶+»+¿]+-+[¢+£+¤+¥+©+®] \p{subhead%3DGeneral+punctuation}+-+[U%2B203F+U%2B2040+U%2B2045+U%2B2046+U%2B2054] \p{subhead%3DDouble+punctuation+for+vertical+text} \p{subhead%3DArchaic+punctuation}+-+[U%2B2E31+U%2B2E33+U%2B2E34+U%2B2E3F] U%2B214B]&g=&i=>
]

The effect of that would be to make 1,628 characters no longer usable as
operators [list of non-operator characters
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[%2F+%3D+\-+%2B+!++%25+%3C+%3E+%5C%26+%7C+%5C%5E+~+%3F%0D%0AU%2B00A1±+U%2B00A7%0D%0AU%2B00A9+U%2B00AB+U%2B00AC+U%2B00AE%0D%0AU%2B00B0±+U%2B00B1%0D%0AU%2B00B6+U%2B00BB+U%2B00BF+U%2B00D7+U%2B00F7%0D%0AU%2B2016±+U%2B2017%0D%0AU%2B2020±+U%2B2027%0D%0AU%2B2030±+U%2B203E%0D%0AU%2B2041±+U%2B2053%0D%0AU%2B2055±+U%2B205E%0D%0AU%2B2190±+U%2B23FF%0D%0AU%2B2500±+U%2B2775%0D%0AU%2B2794±+U%2B2BFF%0D%0AU%2B2E00±+U%2B2E7F%0D%0AU%2B3001±+U%2B3003%0D%0AU%2B3008±+U%2B3030%5D%0D%0A%0D%0A-%5B%5B%3ASm%3A%5D%0D%0A-%5Cp%7BBlock%3DSuperscripts+And+Subscripts%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Technical%7D%0D%0A-%5Cp%7BBlock%3DGeometric+Shapes%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Symbols%7D%0D%0A-%5Cp%7BBlock%3DAlphabetic+Presentation+Forms%7D%0D%0A-%5Cp%7BBlock%3DSmall+Form+Variants%7D%0D%0A-%5Cp%7BBlock%3DHalfwidth+And+Fullwidth+Forms%7D%0D%0A-%5Cp%7BBlock%3DMathematical+Alphanumeric+Symbols%7D%0D%0A-%5Cp%7BBlock%3DArabic+Mathematical+Alphabetic+Symbols%7D%0D%0A-%5Cp%7Bsubhead%3DVariant+letterforms+and+symbols%7D%0D%0A-%5Cp%7Bsubhead%3DLetterlike+symbol%7D%0D%0A%5Cp%7BBlock%3DArrows%7D%0D%0A%5B%2F+%3D+%5C-+%2B+%21++%25+%3C+%3E+%5C%26+%7C+%5C%5E+~+%3F%5D%0D%0A%5B%C2%A1+%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A6+%C2%A7+%C2%A9+%C2%AB+%C2%AC+%C2%AE+%C2%B0+%C2%B1+%C2%B6+%C2%BB+%C2%BF%5D±+%5B%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A9+%C2%AE%5D%0D%0A%5Cp%7Bsubhead%3DGeneral+punctuation%7D±+%5BU%2B203F+U%2B2040+U%2B2045+U%2B2046+U%2B2054%5D%0D%0A%5Cp%7Bsubhead%3DDouble+punctuation+for+vertical+text%7D%0D%0A%5Cp%7Bsubhead%3DArchaic+punctuation%7D±+%5BU%2B2E31+U%2B2E33+U%2B2E34+U%2B2E3F%5D%0D%0AU%2B214B%5D&g=&i=>
]

However, my strategy was to be conservative in accepting operators. There
are several Unicode blocks which contain some additional characters which
we may want to have as operators [list of characters in those blocks
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[\p{Block%3DMiscellaneous+Technical} \p{Block%3DOptical+Character+Recognition} \p{Block%3DBox+Drawing} \p{Block%3DBlock+Elements} \p{Block%3DGeometric+Shapes} \p{Block%3DMiscellaneous+Symbols} \p{Block%3DDingbats} \p{Block%3DBraille} \p{Block%3DMiscellaneous+Symbols+And+Arrows} \p{Block%3DYijing+Hexagram+Symbols} \p{Block%3DMusical+Symbols} \p{Block%3DAncient+Greek+Musical+Notation} \p{Block%3DTai+Xuan+Jing+Symbols} \p{Block%3DMahjong+Tiles} \p{Block%3DDomino+Tiles} \p{Block%3DPlaying+Cards} \p{Block%3DOrnamental+Dingbats} \p{Block%3DAlchemical+Symbols} \p{Block%3DGeometric+Shapes+Extended} \p{Block%3DSupplemental+Arrows+C}] &g=&i=>
]

I did not include the backslash because I decided not to mess with the
choice of ASCII operators, however I do support making backslash an
operator. I am not sure about currency symbols.

Nevin

On Sun, Feb 5, 2017 at 1:20 PM, Dave Abrahams via swift-evolution < >> swift-evolution@swift.org> wrote:

on Sun Feb 05 2017, Nicolas Fezans <swift-evolution@swift.org> wrote:

> Dear all,
>
> This is a rather simple proposal to add '\' (backslash character) as a
> valid operator-head in the swift grammar.
>
> One argument for it, is that there exist a backslash operator in the
> MATLAB/Scilab/Octave languages. In this languages A\B solves the linear
> system A*X = B for X (or the least square problem associated to it if
the
> system of equations is overdetermined). I am doing some numerical
> computation in Swift and it would be nice to be able to declare the same
> operator name for this functionality.
>
> I might have missed some arguments for not adding them, but I seems to
me
> that until now the \ character is only used inside of string literals.
If
> that is the case, both uses should never generate a conflict or be
> ambiguous, isn't it? (String literals keep their interpretation of \
and \
> used otherwise within the swift code will be interpreted as an operator
or
> as the beginning of an operator)
>
> I am curious to see what will be the feedback on this.

+1 if it doesn't clash with the grammar.

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

_______________________________________________
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


#18

Did you look at how my list is constructed? It is almost entirely built
from existing Unicode designations, with only a small number of exceptions.
To wit:

Begin with the category:

Symbol, math

Remove everything from the blocks:

Superscripts And Subscripts
Miscellaneous Technical
Geometric Shapes
Miscellaneous Symbols
Alphabetic Presentation Forms
Small Form Variants
Halfwidth And Fullwidth Forms
Mathematical Alphanumeric Symbols
Arabic Mathematical Alphabetic Symbols

Remove everything from the subheadings:

Variant letterforms and symbols
Letterlike symbol

Add everything from the block

Arrows

Add everything from the subheadings:

Double punctuation for vertical text
General punctuation, EXCEPT [U+203F U+2040 U+2045 U+2046 U+2054]
Archaic punctuation, EXCEPT [U+2E31 U+2E33 U+2E34 U+2E3F]

Add our existing ASCII and Latin-1 operators:

[/ = - + ! * % < > & | ^ ~ ?]

[¡ ¢ £ ¤ ¥ ¦ § © « ¬ ® ° ± ¶ » ¿], EXCEPT [¢ £ ¤ ¥ © ®]

Add the turned ampersand:

U+214B

• • •

This is hardly an ad hoc list, since it is built on existing
classifications and slightly modified to fit our purposes. To it we may add
the backslash (U+005C), and from it remove the empty set (U+2205) and
infinity (U+221E) symbols. Currency signs could go either way, so I have
left them unspecified (hence not operators) for now.

Some discussion about whether to include the following subheadings may be
in order:

Drafting symbols
Miscellaneous technical, EXCEPT [U+23E8]

Beyond that, I think it is fine to leave symbol-like glyphs unspecified for
now, neither operators nor identifiers.

Nevin

···

On Mon, Feb 6, 2017 at 9:34 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Mon, Feb 6, 2017 at 7:36 PM, Nevin Brackett-Rozinsky via > swift-evolution <swift-evolution@swift.org> wrote:

Given that the definition of operator characters in Swift is “part of
Swift”, it follows that any change to that set will go through the Swift
Evolution process, which includes discussion on this list. I do not see a
reasonable way to skip that, nor would I consider it desirable to do so.
Discussing on this list which characters should be operators in Swift is
*prima facie* a necessary part of changing them.

In light of the fact that our current operator-character situation needs
to be fixed—meaning we will have to decide which characters should and
should not be allowed in operators—and seeing as any proposal to solve the
problem will be discussed on this list, the natural conclusion is that
discussing which characters should be operators is *exactly* what we ought
to do.

Moreover, we are trying to decide which operators are right for *Swift*,
thus our goals include expressivity, usefulness, and enjoyability. Our
goals do *not* include being maximally conservative, and indeed I view
parsimony in operator-character availability as undesirable.

We should aim to choose the *right* set of operator characters, for some
Swifty and opinionated value of “right”. If the recommendations that
Unicode settles on strike us as right for Swift, that is great. But those
recommendations do not exist yet, and so far it sounds like they could well
be defined in a way which is *not* right for Swift.

Perhaps Unicode will add a new category for operators, and they will go
character-by-character to put certain glyphs in it. But if they don’t, then
as you say the existing categories are not sufficient for Swift’s purposes,
so their recommendations will not solve our problem. And if they do, we
still would need to verify that their decision matches our use-case.

The past proposal to gut non-ASCII operators from Swift was rightly
blocked, for it would have damaged the language. My follow-up with a list
of 1,020 characters to use as operators has not seen much discussion. If
there were any controversial characters in it or omissions from it, I hope
someone would raise an objection.

In any case, I think that discussing which characters are right for Swift
operators is an entirely proper and expected use of this mailing list, and
I suggest we do so during the Swift 4 timeframe because it affects source
compatibility.

You misunderstand my drift. Of course any such change to Swift would have
to go through this list, and of course that involves asking which
characters are right for Swift operators. The question is _how_ to
undertake a fruitful discussion.

Consider this: that part of our previous draft which concerned adopting
UAX#31 received immediate and almost universal consensus. One technical
report has made it possible to adopt a cogent set of some 100,000-odd
characters for identifiers *without* analyzing each one, with the added
benefit that Swift would be able to parallel the evolution of Unicode in
that respect as the years go on. That analysis involved, exactly as you
say, asking exactly which characters make sense for Swift identifiers, but
did so by means of overarching principles (for example, should aspirational
scripts be included?).

By comparison, that part of the previous draft which concerned matters not
yet settled by Unicode experts prompted vehement disagreement, with great
debate on the minutiae of individual codepoints that never reached
consensus. I too have made a list of 500-1000 operator characters. Several
versions in fact. So did other authors of the previous draft. Some of us
made character-by-character lists. Some also made block-by-block lists. We
carefully considered which operators might overlap with emojis, and which
were confusables, and whether operators require different Unicode
normalization from identifiers. We debated questions such as whether tiny
and miny were mathematical operators or something else. Make no mistake, we
reached no ultimate consensus on a lot of these questions even amongst the
authors.

I have held off on re-introducing this proposal in part because I'm
seriously concerned that, without a better method, such an exercise is
exceedingly poor form on such a high-traffic list. After all, we don't go
line-by-line through draft implementations of proposed features on this
list. We need to be able to articulate useful principles by which
characters outside the ASCII range will be classified as operators;
Jonathan Shapiro has indicated that not even Unicode will proceed with an
ad-hoc character-by-character analysis. If we can come up with overarching
principles that are workable, then it is plausible that Unicode will follow
our lead. So yes, I agree with you absolutely, discussing which characters
are right for Swift operators is an entirely proper and expected use of
this mailing list. Now, _how_ to discuss it? I feel very strongly the
answer is not by scrutiny of a list of codepoints.

In any case, again we've gone far afield. I'm supportive of adding \ as an
operator. That is a standalone proposal with its own merits; would love to
see that proposed and considered on its own.

Nevin

On Mon, Feb 6, 2017 at 7:05 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

Indeed, I'd be thrilled to revise and reintroduce a proposal to update
identifier and operator characters, if co-authors of that proposal are OK
with it. Agree entirely with the principle you enunciate; that is exactly
how we tried to approach it previously. I take it that you agree that a
comprehensive revision of identifier characters cannot happen without
thinking about operator characters, and vice versa, and I believe we came
to that conclusion as well.

Two difficulties arose. Jonathan Shapiro indicated that the Unicode
approach would invariably be to specify which characters are valid
identifiers, etc. not by code points or planes but by "categories," for
which there are none for operators but also for which there are problematic
ones for emoji (the numerals 0-9 belong to the emoji category, for
instance; there is another emoji_presentation category which has its own
tricks). Therefore, we considered that the most conservative way to
classify "definite operators," "definite identifiers," and everything else
was to leave emoji out (UAX31 does not include them as identifier
characters) and to roll back operator characters to the ASCII range.
However, both temporary measures were soundly rejected.

There are a number of security issues to be ironed out with respect to
emoji. For instance, emoji modifiers such as skin tones and genders allow
different identifiers to be made that are visually identical or nearly so.
(And yes, I'm aware that you or I could come up with an ad-hoc solution to
this particular problem with emoji, but the issue is identifying all such
relevant problems and coming up with solutions that jibe with future
Unicode solutions to the same problems.) It would have been nice to leave
this out entirely for now until further guidance from Unicode experts, but
the community made it clear that emoji were a sine qua non.

Likewise, every discussion on operator characters thus far has devolved
into a series of replies nominating specific characters for inclusion. I
continue to believe a character-by-character debate on this mailing list
would be exceptionally poor form. My point in replying to this thread is
only that we don't need to get into any of this (Unicode operators,
canonicalization forms, emoji, etc.--much as I would love to) in order to
consider the isolated addition of an ASCII-range operator \. That idea
seems very reasonable, independently useful, and limited in scope.

On Mon, Feb 6, 2017 at 15:28 Nevin Brackett-Rozinsky via swift-evolution >>> <swift-evolution@swift.org> wrote:

Although there was, as you say, some push-back against revamping our
set of operator characters, there was also substantial push-forward. Many
people want to resolve the problematic situation we currently have
regarding the designation of operators and identifiers.

And indeed, cutting back to ASCII-only operators would have been an
abominable choice. However waiting for the Unicode Consortium to draft
guidelines for operator characters means prolonging our existing
predicament. Additionally, in the discussion last fall it was mentioned
that Unicode personnel are aware of what we are doing with Swift operators,
and that our decisions may help to inform their classification of operator
characters:

On Fri, Oct 21, 2016 at 5:38 PM, Jonathan S. Shapiro < >>>> jonathan.s.shapiro@gmail.com> wrote:

That's a feasible way to go, but keep in mind that the UAX31 changes
are being co-designed with and informed by the current discussion. There
are a bunch of things that have come up here that will allow UAX31 to
side-step some "might have happened" mistakes, so this discussion has been
very useful.

The Swift community can and should make its own decision about whether
to remain engaged. The risk of disengagement is that messy compatibility
issues will probably have to be faced later that we can easily head-off now.

Given all these considerations, I think the principled approach is for
us to move forward with a 3-part categorization of characters into
operators, identifiers, and unspecified (to be determined). That way we
need not harangue ourselves over every controversial glyph, and may instead
quickly determine those characters which should definitely be operators and
those which should definitely be identifiers, while saving the difficult
decisions until such time as Unicode produces recommendations and/or we
decide to undertake a more comprehensive review.

Nevin

On Sun, Feb 5, 2017 at 8:29 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

IIRC, where we left the discussion last time was that there was work
not yet complete within Unicode on delineating identifier and operator
characters. As there was broad agreement to align identifier characters
with Unicode standards, and since the strict separation between identifiers
and operators means that no character should belong to both, there was
hesitation to declare an operator what Unicode may later deem to be an
identifier.

There was strenuous objection to temporarily cutting back operators to
the ASCII range until Unicode completes its work, but also pushback in
going character-by-character above the ASCII range.

In any case, \ seems perfectly reasonable as an additional operator
character that doesn't have to wait for Unicode.

On Sun, Feb 5, 2017 at 19:02 T.J. Usiyan via swift-evolution < >>>> swift-evolution@swift.org> wrote:

+1 from me.

I hope that operators get more work soon, especially with regard to
math.

On Sun, Feb 5, 2017 at 5:09 PM, Nevin Brackett-Rozinsky via >>>> swift-evolution <swift-evolution@swift.org> wrote:

+1 as well. I also support adding these four symbols: ⅀ ؆ ؇ ⅋ as
operators.

There was substantial discussion last fall about revamping operators in
Swift, with the primary goal of removing characters that should not be in
the set. I went through the Unicode tables and compiled a list of 1,020
characters that I think definitely should be operators [list of
operator characters
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[[%3ASm%3A] -\p{Block%3DSuperscripts+And+Subscripts} -\p{Block%3DMiscellaneous+Technical} -\p{Block%3DGeometric+Shapes} -\p{Block%3DMiscellaneous+Symbols} -\p{Block%3DAlphabetic+Presentation+Forms} -\p{Block%3DSmall+Form+Variants} -\p{Block%3DHalfwidth+And+Fullwidth+Forms} -\p{Block%3DMathematical+Alphanumeric+Symbols} -\p{Block%3DArabic+Mathematical+Alphabetic+Symbols} -\p{subhead%3DVariant+letterforms+and+symbols} -\p{subhead%3DLetterlike+symbol} \p{Block%3DArrows} [%2F+%3D+\-+%2B+!+*+%+<+>+\%26+|+\^+~+%3F] [¡+¢+£+¤+¥+¦+§+©+«+¬+®+°+±+¶+»+¿]+-+[¢+£+¤+¥+©+®] \p{subhead%3DGeneral+punctuation}+-+[U%2B203F+U%2B2040+U%2B2045+U%2B2046+U%2B2054] \p{subhead%3DDouble+punctuation+for+vertical+text} \p{subhead%3DArchaic+punctuation}+-+[U%2B2E31+U%2B2E33+U%2B2E34+U%2B2E3F] U%2B214B]&g=&i=>
]

The effect of that would be to make 1,628 characters no longer usable
as operators [list of non-operator characters
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[%2F+%3D+\-+%2B+!++%25+%3C+%3E+%5C%26+%7C+%5C%5E+~+%3F%0D%0AU%2B00A1±+U%2B00A7%0D%0AU%2B00A9+U%2B00AB+U%2B00AC+U%2B00AE%0D%0AU%2B00B0±+U%2B00B1%0D%0AU%2B00B6+U%2B00BB+U%2B00BF+U%2B00D7+U%2B00F7%0D%0AU%2B2016±+U%2B2017%0D%0AU%2B2020±+U%2B2027%0D%0AU%2B2030±+U%2B203E%0D%0AU%2B2041±+U%2B2053%0D%0AU%2B2055±+U%2B205E%0D%0AU%2B2190±+U%2B23FF%0D%0AU%2B2500±+U%2B2775%0D%0AU%2B2794±+U%2B2BFF%0D%0AU%2B2E00±+U%2B2E7F%0D%0AU%2B3001±+U%2B3003%0D%0AU%2B3008±+U%2B3030%5D%0D%0A%0D%0A-%5B%5B%3ASm%3A%5D%0D%0A-%5Cp%7BBlock%3DSuperscripts+And+Subscripts%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Technical%7D%0D%0A-%5Cp%7BBlock%3DGeometric+Shapes%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Symbols%7D%0D%0A-%5Cp%7BBlock%3DAlphabetic+Presentation+Forms%7D%0D%0A-%5Cp%7BBlock%3DSmall+Form+Variants%7D%0D%0A-%5Cp%7BBlock%3DHalfwidth+And+Fullwidth+Forms%7D%0D%0A-%5Cp%7BBlock%3DMathematical+Alphanumeric+Symbols%7D%0D%0A-%5Cp%7BBlock%3DArabic+Mathematical+Alphabetic+Symbols%7D%0D%0A-%5Cp%7Bsubhead%3DVariant+letterforms+and+symbols%7D%0D%0A-%5Cp%7Bsubhead%3DLetterlike+symbol%7D%0D%0A%5Cp%7BBlock%3DArrows%7D%0D%0A%5B%2F+%3D+%5C-+%2B+%21++%25+%3C+%3E+%5C%26+%7C+%5C%5E+~+%3F%5D%0D%0A%5B%C2%A1+%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A6+%C2%A7+%C2%A9+%C2%AB+%C2%AC+%C2%AE+%C2%B0+%C2%B1+%C2%B6+%C2%BB+%C2%BF%5D±+%5B%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A9+%C2%AE%5D%0D%0A%5Cp%7Bsubhead%3DGeneral+punctuation%7D±+%5BU%2B203F+U%2B2040+U%2B2045+U%2B2046+U%2B2054%5D%0D%0A%5Cp%7Bsubhead%3DDouble+punctuation+for+vertical+text%7D%0D%0A%5Cp%7Bsubhead%3DArchaic+punctuation%7D±+%5BU%2B2E31+U%2B2E33+U%2B2E34+U%2B2E3F%5D%0D%0AU%2B214B%5D&g=&i=>
]

However, my strategy was to be conservative in accepting operators.
There are several Unicode blocks which contain some additional characters
which we may want to have as operators [list of characters in those
blocks
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[\p{Block%3DMiscellaneous+Technical} \p{Block%3DOptical+Character+Recognition} \p{Block%3DBox+Drawing} \p{Block%3DBlock+Elements} \p{Block%3DGeometric+Shapes} \p{Block%3DMiscellaneous+Symbols} \p{Block%3DDingbats} \p{Block%3DBraille} \p{Block%3DMiscellaneous+Symbols+And+Arrows} \p{Block%3DYijing+Hexagram+Symbols} \p{Block%3DMusical+Symbols} \p{Block%3DAncient+Greek+Musical+Notation} \p{Block%3DTai+Xuan+Jing+Symbols} \p{Block%3DMahjong+Tiles} \p{Block%3DDomino+Tiles} \p{Block%3DPlaying+Cards} \p{Block%3DOrnamental+Dingbats} \p{Block%3DAlchemical+Symbols} \p{Block%3DGeometric+Shapes+Extended} \p{Block%3DSupplemental+Arrows+C}] &g=&i=>
]

I did not include the backslash because I decided not to mess with the
choice of ASCII operators, however I do support making backslash an
operator. I am not sure about currency symbols.

Nevin

On Sun, Feb 5, 2017 at 1:20 PM, Dave Abrahams via swift-evolution < >>>> swift-evolution@swift.org> wrote:

on Sun Feb 05 2017, Nicolas Fezans <swift-evolution@swift.org> wrote:

> Dear all,
>
> This is a rather simple proposal to add '\' (backslash character) as a
> valid operator-head in the swift grammar.
>
> One argument for it, is that there exist a backslash operator in the
> MATLAB/Scilab/Octave languages. In this languages A\B solves the
linear
> system A*X = B for X (or the least square problem associated to it if
the
> system of equations is overdetermined). I am doing some numerical
> computation in Swift and it would be nice to be able to declare the
same
> operator name for this functionality.
>
> I might have missed some arguments for not adding them, but I seems
to me
> that until now the \ character is only used inside of string
literals. If
> that is the case, both uses should never generate a conflict or be
> ambiguous, isn't it? (String literals keep their interpretation of \
and \
> used otherwise within the swift code will be interpreted as an
operator or
> as the beginning of an operator)
>
> I am curious to see what will be the feedback on this.

+1 if it doesn't clash with the grammar.

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

_______________________________________________
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


(Xiaodi Wu) #19

I did look at your list; as I said, I and others have made similar lists
before and have discovered their specific weaknesses. Again, I very much
think this is not going to be a fruitful on-list approach, and certainly
it's not appropriate for this particular thread. I will reply offlist with
specific insights.

···

On Mon, Feb 6, 2017 at 21:05 Nevin Brackett-Rozinsky < nevin.brackettrozinsky@gmail.com> wrote:

Did you look at how my list is constructed? It is almost entirely built
from existing Unicode designations, with only a small number of exceptions.
To wit:

Begin with the category:

Symbol, math

Remove everything from the blocks:

Superscripts And Subscripts
Miscellaneous Technical
Geometric Shapes
Miscellaneous Symbols
Alphabetic Presentation Forms
Small Form Variants
Halfwidth And Fullwidth Forms
Mathematical Alphanumeric Symbols
Arabic Mathematical Alphabetic Symbols

Remove everything from the subheadings:

Variant letterforms and symbols
Letterlike symbol

Add everything from the block

Arrows

Add everything from the subheadings:

Double punctuation for vertical text
General punctuation, EXCEPT [U+203F U+2040 U+2045 U+2046 U+2054]
Archaic punctuation, EXCEPT [U+2E31 U+2E33 U+2E34 U+2E3F]

Add our existing ASCII and Latin-1 operators:

[/ = - + ! * % < > & | ^ ~ ?]

[¡ ¢ £ ¤ ¥ ¦ § © « ¬ ® ° ± ¶ » ¿], EXCEPT [¢ £ ¤ ¥ © ®]

Add the turned ampersand:

U+214B

• • •

This is hardly an ad hoc list, since it is built on existing
classifications and slightly modified to fit our purposes. To it we may add
the backslash (U+005C), and from it remove the empty set (U+2205) and
infinity (U+221E) symbols. Currency signs could go either way, so I have
left them unspecified (hence not operators) for now.

Some discussion about whether to include the following subheadings may be
in order:

Drafting symbols
Miscellaneous technical, EXCEPT [U+23E8]

Beyond that, I think it is fine to leave symbol-like glyphs unspecified
for now, neither operators nor identifiers.

Nevin

On Mon, Feb 6, 2017 at 9:34 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Mon, Feb 6, 2017 at 7:36 PM, Nevin Brackett-Rozinsky via > swift-evolution <swift-evolution@swift.org> wrote:

Given that the definition of operator characters in Swift is “part of
Swift”, it follows that any change to that set will go through the Swift
Evolution process, which includes discussion on this list. I do not see a
reasonable way to skip that, nor would I consider it desirable to do so.
Discussing on this list which characters should be operators in Swift is
*prima facie* a necessary part of changing them.

In light of the fact that our current operator-character situation needs
to be fixed—meaning we will have to decide which characters should and
should not be allowed in operators—and seeing as any proposal to solve the
problem will be discussed on this list, the natural conclusion is that
discussing which characters should be operators is *exactly* what we ought
to do.

Moreover, we are trying to decide which operators are right for *Swift*,
thus our goals include expressivity, usefulness, and enjoyability. Our
goals do *not* include being maximally conservative, and indeed I view
parsimony in operator-character availability as undesirable.

We should aim to choose the *right* set of operator characters, for some
Swifty and opinionated value of “right”. If the recommendations that
Unicode settles on strike us as right for Swift, that is great. But those
recommendations do not exist yet, and so far it sounds like they could well
be defined in a way which is *not* right for Swift.

Perhaps Unicode will add a new category for operators, and they will go
character-by-character to put certain glyphs in it. But if they don’t, then
as you say the existing categories are not sufficient for Swift’s purposes,
so their recommendations will not solve our problem. And if they do, we
still would need to verify that their decision matches our use-case.

The past proposal to gut non-ASCII operators from Swift was rightly
blocked, for it would have damaged the language. My follow-up with a list
of 1,020 characters to use as operators has not seen much discussion. If
there were any controversial characters in it or omissions from it, I hope
someone would raise an objection.

In any case, I think that discussing which characters are right for Swift
operators is an entirely proper and expected use of this mailing list, and
I suggest we do so during the Swift 4 timeframe because it affects source
compatibility.

You misunderstand my drift. Of course any such change to Swift would have
to go through this list, and of course that involves asking which
characters are right for Swift operators. The question is _how_ to
undertake a fruitful discussion.

Consider this: that part of our previous draft which concerned adopting
UAX#31 received immediate and almost universal consensus. One technical
report has made it possible to adopt a cogent set of some 100,000-odd
characters for identifiers *without* analyzing each one, with the added
benefit that Swift would be able to parallel the evolution of Unicode in
that respect as the years go on. That analysis involved, exactly as you
say, asking exactly which characters make sense for Swift identifiers, but
did so by means of overarching principles (for example, should aspirational
scripts be included?).

By comparison, that part of the previous draft which concerned matters not
yet settled by Unicode experts prompted vehement disagreement, with great
debate on the minutiae of individual codepoints that never reached
consensus. I too have made a list of 500-1000 operator characters. Several
versions in fact. So did other authors of the previous draft. Some of us
made character-by-character lists. Some also made block-by-block lists. We
carefully considered which operators might overlap with emojis, and which
were confusables, and whether operators require different Unicode
normalization from identifiers. We debated questions such as whether tiny
and miny were mathematical operators or something else. Make no mistake, we
reached no ultimate consensus on a lot of these questions even amongst the
authors.

I have held off on re-introducing this proposal in part because I'm
seriously concerned that, without a better method, such an exercise is
exceedingly poor form on such a high-traffic list. After all, we don't go
line-by-line through draft implementations of proposed features on this
list. We need to be able to articulate useful principles by which
characters outside the ASCII range will be classified as operators;
Jonathan Shapiro has indicated that not even Unicode will proceed with an
ad-hoc character-by-character analysis. If we can come up with overarching
principles that are workable, then it is plausible that Unicode will follow
our lead. So yes, I agree with you absolutely, discussing which characters
are right for Swift operators is an entirely proper and expected use of
this mailing list. Now, _how_ to discuss it? I feel very strongly the
answer is not by scrutiny of a list of codepoints.

In any case, again we've gone far afield. I'm supportive of adding \ as an
operator. That is a standalone proposal with its own merits; would love to
see that proposed and considered on its own.

Nevin

On Mon, Feb 6, 2017 at 7:05 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

Indeed, I'd be thrilled to revise and reintroduce a proposal to update
identifier and operator characters, if co-authors of that proposal are OK
with it. Agree entirely with the principle you enunciate; that is exactly
how we tried to approach it previously. I take it that you agree that a
comprehensive revision of identifier characters cannot happen without
thinking about operator characters, and vice versa, and I believe we came
to that conclusion as well.

Two difficulties arose. Jonathan Shapiro indicated that the Unicode
approach would invariably be to specify which characters are valid
identifiers, etc. not by code points or planes but by "categories," for
which there are none for operators but also for which there are problematic
ones for emoji (the numerals 0-9 belong to the emoji category, for
instance; there is another emoji_presentation category which has its own
tricks). Therefore, we considered that the most conservative way to
classify "definite operators," "definite identifiers," and everything else
was to leave emoji out (UAX31 does not include them as identifier
characters) and to roll back operator characters to the ASCII range.
However, both temporary measures were soundly rejected.

There are a number of security issues to be ironed out with respect to
emoji. For instance, emoji modifiers such as skin tones and genders allow
different identifiers to be made that are visually identical or nearly so.
(And yes, I'm aware that you or I could come up with an ad-hoc solution to
this particular problem with emoji, but the issue is identifying all such
relevant problems and coming up with solutions that jibe with future
Unicode solutions to the same problems.) It would have been nice to leave
this out entirely for now until further guidance from Unicode experts, but
the community made it clear that emoji were a sine qua non.

Likewise, every discussion on operator characters thus far has devolved
into a series of replies nominating specific characters for inclusion. I
continue to believe a character-by-character debate on this mailing list
would be exceptionally poor form. My point in replying to this thread is
only that we don't need to get into any of this (Unicode operators,
canonicalization forms, emoji, etc.--much as I would love to) in order to
consider the isolated addition of an ASCII-range operator \. That idea
seems very reasonable, independently useful, and limited in scope.

On Mon, Feb 6, 2017 at 15:28 Nevin Brackett-Rozinsky via swift-evolution < > swift-evolution@swift.org> wrote:

Although there was, as you say, some push-back against revamping our set
of operator characters, there was also substantial push-forward. Many
people want to resolve the problematic situation we currently have
regarding the designation of operators and identifiers.

And indeed, cutting back to ASCII-only operators would have been an
abominable choice. However waiting for the Unicode Consortium to draft
guidelines for operator characters means prolonging our existing
predicament. Additionally, in the discussion last fall it was mentioned
that Unicode personnel are aware of what we are doing with Swift operators,
and that our decisions may help to inform their classification of operator
characters:

On Fri, Oct 21, 2016 at 5:38 PM, Jonathan S. Shapiro < > jonathan.s.shapiro@gmail.com> wrote:

That's a feasible way to go, but keep in mind that the UAX31 changes are
being co-designed with and informed by the current discussion. There are a
bunch of things that have come up here that will allow UAX31 to side-step
some "might have happened" mistakes, so this discussion has been very
useful.

The Swift community can and should make its own decision about whether to
remain engaged. The risk of disengagement is that messy compatibility
issues will probably have to be faced later that we can easily head-off now.

Given all these considerations, I think the principled approach is for us
to move forward with a 3-part categorization of characters into operators,
identifiers, and unspecified (to be determined). That way we need not
harangue ourselves over every controversial glyph, and may instead quickly
determine those characters which should definitely be operators and those
which should definitely be identifiers, while saving the difficult
decisions until such time as Unicode produces recommendations and/or we
decide to undertake a more comprehensive review.

Nevin

On Sun, Feb 5, 2017 at 8:29 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

IIRC, where we left the discussion last time was that there was work not
yet complete within Unicode on delineating identifier and operator
characters. As there was broad agreement to align identifier characters
with Unicode standards, and since the strict separation between identifiers
and operators means that no character should belong to both, there was
hesitation to declare an operator what Unicode may later deem to be an
identifier.

There was strenuous objection to temporarily cutting back operators to the
ASCII range until Unicode completes its work, but also pushback in going
character-by-character above the ASCII range.

In any case, \ seems perfectly reasonable as an additional operator
character that doesn't have to wait for Unicode.

On Sun, Feb 5, 2017 at 19:02 T.J. Usiyan via swift-evolution < > swift-evolution@swift.org> wrote:

+1 from me.

I hope that operators get more work soon, especially with regard to math.

On Sun, Feb 5, 2017 at 5:09 PM, Nevin Brackett-Rozinsky via > swift-evolution <swift-evolution@swift.org> wrote:

+1 as well. I also support adding these four symbols: ⅀ ؆ ؇ ⅋ as
operators.

There was substantial discussion last fall about revamping operators in
Swift, with the primary goal of removing characters that should not be in
the set. I went through the Unicode tables and compiled a list of 1,020
characters that I think definitely should be operators [list of operator
characters
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[[%3ASm%3A] -\p{Block%3DSuperscripts+And+Subscripts} -\p{Block%3DMiscellaneous+Technical} -\p{Block%3DGeometric+Shapes} -\p{Block%3DMiscellaneous+Symbols} -\p{Block%3DAlphabetic+Presentation+Forms} -\p{Block%3DSmall+Form+Variants} -\p{Block%3DHalfwidth+And+Fullwidth+Forms} -\p{Block%3DMathematical+Alphanumeric+Symbols} -\p{Block%3DArabic+Mathematical+Alphabetic+Symbols} -\p{subhead%3DVariant+letterforms+and+symbols} -\p{subhead%3DLetterlike+symbol} \p{Block%3DArrows} [%2F+%3D+\-+%2B+!+*+%+<+>+\%26+|+\^+~+%3F] [¡+¢+£+¤+¥+¦+§+©+«+¬+®+°+±+¶+»+¿]+-+[¢+£+¤+¥+©+®] \p{subhead%3DGeneral+punctuation}+-+[U%2B203F+U%2B2040+U%2B2045+U%2B2046+U%2B2054] \p{subhead%3DDouble+punctuation+for+vertical+text} \p{subhead%3DArchaic+punctuation}+-+[U%2B2E31+U%2B2E33+U%2B2E34+U%2B2E3F] U%2B214B]&g=&i=>
]

The effect of that would be to make 1,628 characters no longer usable as
operators [list of non-operator characters
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[%2F+%3D+\-+%2B+!++%25+%3C+%3E+%5C%26+%7C+%5C%5E+~+%3F%0D%0AU%2B00A1±+U%2B00A7%0D%0AU%2B00A9+U%2B00AB+U%2B00AC+U%2B00AE%0D%0AU%2B00B0±+U%2B00B1%0D%0AU%2B00B6+U%2B00BB+U%2B00BF+U%2B00D7+U%2B00F7%0D%0AU%2B2016±+U%2B2017%0D%0AU%2B2020±+U%2B2027%0D%0AU%2B2030±+U%2B203E%0D%0AU%2B2041±+U%2B2053%0D%0AU%2B2055±+U%2B205E%0D%0AU%2B2190±+U%2B23FF%0D%0AU%2B2500±+U%2B2775%0D%0AU%2B2794±+U%2B2BFF%0D%0AU%2B2E00±+U%2B2E7F%0D%0AU%2B3001±+U%2B3003%0D%0AU%2B3008±+U%2B3030%5D%0D%0A%0D%0A-%5B%5B%3ASm%3A%5D%0D%0A-%5Cp%7BBlock%3DSuperscripts+And+Subscripts%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Technical%7D%0D%0A-%5Cp%7BBlock%3DGeometric+Shapes%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Symbols%7D%0D%0A-%5Cp%7BBlock%3DAlphabetic+Presentation+Forms%7D%0D%0A-%5Cp%7BBlock%3DSmall+Form+Variants%7D%0D%0A-%5Cp%7BBlock%3DHalfwidth+And+Fullwidth+Forms%7D%0D%0A-%5Cp%7BBlock%3DMathematical+Alphanumeric+Symbols%7D%0D%0A-%5Cp%7BBlock%3DArabic+Mathematical+Alphabetic+Symbols%7D%0D%0A-%5Cp%7Bsubhead%3DVariant+letterforms+and+symbols%7D%0D%0A-%5Cp%7Bsubhead%3DLetterlike+symbol%7D%0D%0A%5Cp%7BBlock%3DArrows%7D%0D%0A%5B%2F+%3D+%5C-+%2B+%21++%25+%3C+%3E+%5C%26+%7C+%5C%5E+~+%3F%5D%0D%0A%5B%C2%A1+%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A6+%C2%A7+%C2%A9+%C2%AB+%C2%AC+%C2%AE+%C2%B0+%C2%B1+%C2%B6+%C2%BB+%C2%BF%5D±+%5B%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A9+%C2%AE%5D%0D%0A%5Cp%7Bsubhead%3DGeneral+punctuation%7D±+%5BU%2B203F+U%2B2040+U%2B2045+U%2B2046+U%2B2054%5D%0D%0A%5Cp%7Bsubhead%3DDouble+punctuation+for+vertical+text%7D%0D%0A%5Cp%7Bsubhead%3DArchaic+punctuation%7D±+%5BU%2B2E31+U%2B2E33+U%2B2E34+U%2B2E3F%5D%0D%0AU%2B214B%5D&g=&i=>
]

However, my strategy was to be conservative in accepting operators. There
are several Unicode blocks which contain some additional characters which
we may want to have as operators [list of characters in those blocks
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[\p{Block%3DMiscellaneous+Technical} \p{Block%3DOptical+Character+Recognition} \p{Block%3DBox+Drawing} \p{Block%3DBlock+Elements} \p{Block%3DGeometric+Shapes} \p{Block%3DMiscellaneous+Symbols} \p{Block%3DDingbats} \p{Block%3DBraille} \p{Block%3DMiscellaneous+Symbols+And+Arrows} \p{Block%3DYijing+Hexagram+Symbols} \p{Block%3DMusical+Symbols} \p{Block%3DAncient+Greek+Musical+Notation} \p{Block%3DTai+Xuan+Jing+Symbols} \p{Block%3DMahjong+Tiles} \p{Block%3DDomino+Tiles} \p{Block%3DPlaying+Cards} \p{Block%3DOrnamental+Dingbats} \p{Block%3DAlchemical+Symbols} \p{Block%3DGeometric+Shapes+Extended} \p{Block%3DSupplemental+Arrows+C}] &g=&i=>
]

I did not include the backslash because I decided not to mess with the
choice of ASCII operators, however I do support making backslash an
operator. I am not sure about currency symbols.

Nevin

On Sun, Feb 5, 2017 at 1:20 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:

on Sun Feb 05 2017, Nicolas Fezans <swift-evolution@swift.org> wrote:

> Dear all,
>
> This is a rather simple proposal to add '\' (backslash character) as a
> valid operator-head in the swift grammar.
>
> One argument for it, is that there exist a backslash operator in the
> MATLAB/Scilab/Octave languages. In this languages A\B solves the linear
> system A*X = B for X (or the least square problem associated to it if the
> system of equations is overdetermined). I am doing some numerical
> computation in Swift and it would be nice to be able to declare the same
> operator name for this functionality.
>
> I might have missed some arguments for not adding them, but I seems to me
> that until now the \ character is only used inside of string literals. If
> that is the case, both uses should never generate a conflict or be
> ambiguous, isn't it? (String literals keep their interpretation of \ and
\
> used otherwise within the swift code will be interpreted as an operator
or
> as the beginning of an operator)
>
> I am curious to see what will be the feedback on this.

+1 if it doesn't clash with the grammar.

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

_______________________________________________
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