On Dec 17, 2015, at 4:19 PM, Chris Lattner <email@example.com> wrote:
On Dec 17, 2015, at 4:15 PM, Greg Parker via swift-evolution < > firstname.lastname@example.org> wrote:
On Dec 17, 2015, at 12:14 PM, Ethan Tira-Thompson via swift-evolution < > email@example.com> wrote:
I wanted to use ‘·’ as a dot-product operator, but it’s not currently
defined as an operator character. (rdar://problem/23930008 suggested I
come here for comment.)
Note that dot operator (⋅, U+22C5) is already available for operators and
semantically appropriate, but Mac users can conveniently type
option-shift-9 to get the middle dot which is a nice feature and
consequently it’s more well-known. FWIW, we have U+00B6 (¶) already
defined as an operator, this would extend its range by one.
IHNTA, IJWTS " is an identifier but ︎ is an operator, according to
Swift's current rules.”
I’m not sure what the initialisicms stand for, but any proposal that
let = "moof"
will not be tolerated.
Perhaps there’s a way to avoid having to statically classify all of
unicode into operator vs. identifier characters?
For example, could this be done dynamically, where the compiler tracks the
characters used for each group as it goes, and only complains if it
encounters a conflict with a previous declaration?
This does introduce a possibility to have conflicts between a piece of
code and an imported API, but the odds of a conflict seem on the scale of
other namespace clashes. (Much less IMHO, and even in the case of such a
conflict, are we really better suited to have preemptively decided between
If nothing else, debating individual characters like this seems like it
will get old really fast, and runs a similar risk of conflicts with
pre-existing code on each change. (perhaps greater actually since it’s
globally enforced rather than scoped by individual import.)
swift-evolution mailing list