Request to add middle dot (U+00B7) as operator character?

Ethan_Tira-Thompson · December 17, 2015, 8:14pm

Hi swift-evolution,

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.

Thoughts?

Thanks,
-Ethan

gparker42 · December 18, 2015, 12:15am

IHNTA, IJWTS " is an identifier but ︎ is an operator, according to Swift's current rules."

···

On Dec 17, 2015, at 12:14 PM, Ethan Tira-Thompson via swift-evolution <swift-evolution@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.

--
Greg Parker gparker@apple.com Runtime Wrangler

Radek_Pietruszewski · December 17, 2015, 10:35pm

Although I would personally never, ever want to do this, I see no reason why this character shouldn’t be allowed for an operator.

The question is: if we are to touch this are and extend the Unicode ranges of characters allowed for operators, what else is missing? A wider proposal to fill in the blanks would probably make sense.

— Radek

···

On 17 Dec 2015, at 21:14, Ethan Tira-Thompson via swift-evolution <swift-evolution@swift.org> wrote:

Hi swift-evolution,

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.

Thoughts?

Thanks,
-Ethan

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

Per_Melin · December 20, 2015, 9:31am

Unrelated to this discussion, but please take care making assumptions like
that, at least for open source code. For example, on my (Swedish) keyboard,
option-shift-9 gets me '}'. I did eventually manage to find your middle dot
on option-shift-. but that does not mean that it can be produced on other
non-English keyboard layouts.

When your alphabet has more than 26 letters but the number of keys on the
keyboard stays the same, a lot gets reshuffled and sometimes lost.

···

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

<snip> but Mac users can conveniently type option-shift-9 to get the
middle dot <snip>

Chris_Lattner · December 17, 2015, 11:50pm

Although I would personally never, ever want to do this, I see no reason why this character shouldn’t be allowed for an operator.

The question is: if we are to touch this are and extend the Unicode ranges of characters allowed for operators, what else is missing? A wider proposal to fill in the blanks would probably make sense.

Right. I also agree that adding this specific character makes sense, and it is trivial to extend the set of characters supported:

github.com

apple/swift/blob/main/include/swift/AST/Identifier.h#L90


      
          
          public:
            explicit Identifier() : Pointer(nullptr) {}
            
            const char *get() const { return Pointer; }
            
            StringRef str() const { return Pointer; }
          
            explicit operator std::string() const { return std::string(Pointer); }
          
            unsigned getLength() const {
              assert(Pointer != nullptr && "Tried getting length of empty identifier");
              return ::strlen(Pointer);
            }
            
            bool empty() const { return Pointer == nullptr; }
            bool nonempty() const { return !empty(); }
          
            LLVM_ATTRIBUTE_USED bool is(StringRef string) const {
              return str().equals(string);
            }

The question is: what is the right set of characters? It would be great for someone familiar with this space to dive in and try to rationalize it.

-Chris

···

On Dec 17, 2015, at 2:35 PM, Radosław Pietruszewski via swift-evolution <swift-evolution@swift.org> wrote:

— Radek

On 17 Dec 2015, at 21:14, Ethan Tira-Thompson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi swift-evolution,

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.

Thoughts?

Thanks,
-Ethan

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

Chris_Lattner · December 18, 2015, 12:19am

I’m not sure what the initialisicms stand for, but any proposal that breaks:

let = "moof"

will not be tolerated. :-) :-)

-Chris

···

On Dec 17, 2015, at 4:15 PM, Greg Parker via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 17, 2015, at 12:14 PM, Ethan Tira-Thompson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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.”

Andrew · December 17, 2015, 11:55pm

I've definitely wanted to use some unavailable characters. I've also wanted
to add a postfix Greek question mark operator to my friend's code, but
that's a different issue.

···

On Friday, 18 December 2015, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

On Dec 17, 2015, at 2:35 PM, Radosław Pietruszewski via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

Although I would personally never, ever want to do this, I see no reason
why this character shouldn’t be allowed for an operator.

The question is: if we are to touch this are and extend the Unicode ranges
of characters allowed for operators, what else is missing? A wider proposal
to fill in the blanks would probably make sense.

Right. I also agree that adding this specific character makes sense, and
it is trivial to extend the set of characters supported:

https://github.com/apple/swift/blob/master/include/swift/AST/Identifier.h#L90

The question is: what is the right set of characters? It would be great
for someone familiar with this space to dive in and try to rationalize it.

-Chris

— Radek

On 17 Dec 2015, at 21:14, Ethan Tira-Thompson via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

Hi swift-evolution,

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.

Thoughts?

Thanks,
-Ethan
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

Ethan_Tira-Thompson · December 18, 2015, 2:05am

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

···

On Dec 17, 2015, at 4:19 PM, Chris Lattner <clattner@apple.com> wrote:

On Dec 17, 2015, at 4:15 PM, Greg Parker via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 17, 2015, at 12:14 PM, Ethan Tira-Thompson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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

Ross_O_Brien1 · December 18, 2015, 1:50am

I've been wanting to ask about how the Swift team decided to split the
Unicode characters between identifier characters and operator characters
for over a year now.
Playing cards and dominoes can be used as identifier characters. Chess
pieces are operator characters. 🂡 ♔
<https://en.wikipedia.org/wiki/♔> 🁄 could be a legal expression in
Swift. I don't know why.
There's a proposal in swift-evolution right now for && and || to be
replaced by 'and' and 'or'. The unicode rules mean that it's not permitted
to create a custom operator 'and' - unless you spell it in Braille.
(Technically Unicode doesn't map Braille symbols to letters, but it's true
as far as it goes).
Care to elaborate on the rationale for this? :)

Ross

···

On Fri, Dec 18, 2015 at 12:19 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

On Dec 17, 2015, at 4:15 PM, Greg Parker via swift-evolution < > swift-evolution@swift.org> wrote:

On Dec 17, 2015, at 12:14 PM, Ethan Tira-Thompson via swift-evolution < > swift-evolution@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

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

jtbandes · December 18, 2015, 2:37am

For reference, here are the sets Haskell uses:

Jacob Bandes-Storch

···

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

On Dec 17, 2015, at 4:19 PM, Chris Lattner <clattner@apple.com> wrote:

On Dec 17, 2015, at 4:15 PM, Greg Parker via swift-evolution < > swift-evolution@swift.org> wrote:

On Dec 17, 2015, at 12:14 PM, Ethan Tira-Thompson via swift-evolution < > swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution