[swift-evolution] Unicode identifiers & operators
Jacob Bandes-Storch
jtbandes at gmail.com
Thu Sep 22 01:05:22 CDT 2016
On Sun, Sep 18, 2016 at 6:34 PM, Robert Widmann <devteam.codafi at gmail.com>
wrote:
> Some thoughts
>
> On Sep 18, 2016, at 3:33 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> *TL;DR:*
>
> Swift 4 Stage 1 seeks to prioritize "Source stability features". Most
> source-breaking changes were done with in Swift 3; however, the
> categorization of Unicode characters into identifiers & operators was never
> thoroughly discussed on swift-evolution. This seems like it might be our
> last chance, and I think there are some big improvements to be had.
>
> I've gathered some information+thoughts into an early-stage pitch /
> pre-proposal. It doesn't really have a conclusion, so I'm hoping we can
> discuss these issues and come up with good (pragmatic) solutions here. I
> imagine this can morph into a proposal later.
>
> You can read the following in nicer HTML form at https://gist.github.com/
> jtbandes/c0b0c072181dcd22c3147802025d0b59
>
> I look forward to the discussion!
>
> -Jacob
>
> *# Background and motivation*
>
> To ease lexing/parsing and avoid user confusion, the names of custom
> identifiers (type names, variable names, etc.) and operators in Swift can
> be composed of (mostly) separate sets of characters.
>
> Using terminology from TSPL:
>
> `identifier-head`/`operator-head` are characters which can *begin *an
> identifier or operator.
>
> `identifier-character`/`operator-character` are characters which can
> appear anywhere in an identifier or operator (these are supersets of the
> `-head` sets).
>
> <https://developer.apple.com/library/content/documentation/
> Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html>
>
> (Note also that some particular arrangements of characters are reserved;
> for instance, `$` followed by digits for an implicit closure parameter, and
> "If an operator doesn’t begin with a dot, it can’t contain a dot
> elsewhere." There are also special characters in the language which are
> neither identifiers nor operators, such as: `()[]{},:@#`)
>
>
> *## Prior discussion on swift-evolution*
>
> *"Request to add middle dot (U+00B7) as operator character?"*
> <https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20151214/003176.html>
>
> *"Free the '$' Symbol!"*
> <https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20151228/005133.html>
>
> *"Proposal: Allow Single Dollar Sign as Valid Identifier"*
> <https://github.com/apple/swift-evolution/pull/354>
>
>
> Chris Lattner has said:
>
> > "...our current operator space (particularly the unicode segments
> covered) is not super well considered. It would be great for someone to
> take a more systematic pass over them to rationalize things."
>
> > "We need a token to be unambiguously an operator or identifier - we can
> have different rules for the leading and subsequent characters though."
>
>
> I feel a bit bad having implemented the patch that banned this - it feels
> like dollar was mistakenly left out of the operator character range
> considering how well it worked in operators up to then. Disambiguation
> with respect to other language constructs (anonymous parameters in closures
> and LLDB variables) is trivial and we already had diagnostics about it.
>
But more importantly, you were also the one who first asked for it to be an
operator character :-)
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/005133.html
Did you have a formal proposal in the works for this? If so, it might be
worth reviewing separately from any other changes. $ is a more well-known
character, and probably more likely to elicit opinions than some more
obscure Unicode stuff.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160921/0d3fe98a/attachment.html>
More information about the swift-evolution
mailing list