[swift-evolution] Request to add middle dot (U+00B7) as operator character?

[Jacob Bandes-Storch]

For reference, here are the sets Haskell uses:
http://stackoverflow.com/a/10616227

Jacob Bandes-Storch

On Thu, Dec 17, 2015 at 6:05 PM, Ethan Tira-Thompson via swift-evolution <
swift-evolution at swift.org> wrote:

> On Dec 17, 2015, at 4:19 PM, Chris Lattner <clattner at apple.com> wrote:
>
>
> On Dec 17, 2015, at 4:15 PM, Greg Parker via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Dec 17, 2015, at 12:14 PM, Ethan Tira-Thompson via swift-evolution <
> swift-evolution at swift.org> 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
> breaks:
>
> let 🐶🐮 = "moof"
>
> will not be tolerated.  :-) :-)
>
> -Chris
>
>
> 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
> them?)
>
> 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.)
>
> -Ethan
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151217/6a6417c6/attachment.html>