I think ★ is fine because it's explicitly filled in and you don't usually have filled in characters in regular writing. I would even apply this to things like ♠ and ♥ in contrast to ♤ and ♡. Something like ◸ does not have a filled in variant but could still make sense as a niche operator. Things like ⛟ more obviously represent nouns than verbs so they don't make sense as operators but they will look ugly in identifiers.
IMO the important part is that operators can help express ourselves better. a ♥ b could make perfect sense in your codebase and express what is happening better compared to an identifier or another operator. I don't think it hurts anyone if that was the only possible way to use ♥ though, that is, not being able to use it in an identifier. I assumed the point of being restrictive up to this point was that precedence would be hard to decide since it's hardcoded.
The issue of how hard the characters are to write can be mitigated by editors. In fact I would say the reason editors don't have unicode support already is because languages don't allow them to be used.
For dot operators, one idea is to have some dot characters be interchangeable with each other, as in they are treated as the same character. Don't know if bullet should be included though.
Well I don't see what's wrong with how the RFC went and why the particular set of operators is problematic. Supporting all of Unicode seems crazy, esp since Unicode keeps changing.
Unicode operators are like salt in a soup, it tastes well when used with care.
Well I don't see what's wrong with how the RFC went
I think it went very well; maybe I should have put my thoughts into another RFC. It began for me as a question, but of course, as I dug deeper my opinions started to crystallize.
Reading back, i realize my snarky 'cargo cult' comment could be interpreted as applying to the rfc participants, when my intention was to throw shade on Julia and the unicode consortium. Sorry.
why the particular set of operators is problematic.
other than black star and bullet operator, the set is easy to reason about, especially when entering characters by name.
circled dot operator, squared dot operator... bullet operator?
Supporting all of Unicode seems crazy
it tastes well when used with care
I couldn't agree more, and I do trust you and all the contributors to act with more care than Julia in this.
For my part, I'm asking what are the first principles upon which:
the important part is that operators can help express ourselves better. a ♥ b could make perfect sense
This is a perfectly reasonable principle by which to select operators for inclusion, and I could see that as the answer to my question.
Maximizing mutual distinction is a strong argument for black star, along with: ⭍ ⭗ ⯌ ⥺⭄ ⭅ ⭆ ⬳ ⟿ ⬱ ⇶ etc Verb-like operators are a much wider and subjective category, maybe even ⚔⚒⚖♋︎
There are no "first principles" we adhere to here, some operators are missing, others are questionable to include, others are hard to distinguish from others but that depends on the font and others are currently hard to type.
I'm skeptical that we could come up with "principles" here that will stand the test of time, except maybe for this: "Operator X was included because it's a "real" common unary/binary operator in a relevant field of math". Note how this would exclude ∑ as it's not "real", it's a unary operator with typically plenty of subscripts.
With regards to ease of entry, I've updated the table to show the operators for which vim digraphs exist.
Inclusion in that particular list is in practice critical for at least me; I suggest it's one of the considerations if/when any more unicode is added (e.g. more brackets)