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

Ethan Tira-Thompson etirathompson at apple.com
Thu Dec 17 20:05:30 CST 2015


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151217/185a9558/attachment.html>


More information about the swift-evolution mailing list