Proposal: allow Math Symbols in identifiers

[awaw...@gmail.com]

I wonder what does the Go team think about allowing Math Symbols in identifiers?

My need is to simplify my quantum computing code for tensor products:

```

func ⊗(ops *tensor.Dense) *tensor.Dense {...}

cnot := ⊗(one, one, σX) + ...

```

As shown above, the Pauli matrix σX works nicely, but the product ⊗ unfortunately doesn't.

One drawback is that people may worry this will make code less readable.

But I think anyone who has overcome the math in any quantum textbook would find allowing Math Symbols actually improving readability due to tighter adherence to papers!

In particular, I propose to edit the Go spec's source code representation section to

```

Go treats all characters in any of the Letter categories Lu, Ll, Lt, Lm, Lo, Sm as Unicode letters.

```

(the Sm <Math Symbol> category is added)

There's this related issue, but that issue was more of a question than a proposal.

[Dan Kortschak]

On Wed, 2025-10-01 at 00:42 -0700, awaw...@gmail.com wrote:
> func ⊗(ops *tensor.Dense) *tensor.Dense {...}

Please no. Including these make the code much harder to work in as it
is harder to search for and while the symbols may be meaningful to the
author, code consumers find it harder. If you need maths symbols, put
them in the godoc.

[awaw...@gmail.com]

Thanks for chiming in.

I wonder could you or others elaborate on why allowing math symbols would make it harder than present to search for?

At present, in Go we can already do Japanese hiragana and katagana, not to mention emojis, whose search requirements are no different than Math symbols.

In fact, I use the ancient Vim editor (without any plugins) as I'm old fashioned, and Vim doesn't seem to have issues searching for "⊗".

I suppose the search experience is even better in VSCode or github.

Regarding the concern that:

> symbols may be meaningful to the author, code consumers find it harder.

At present, Go supports ℏ (reduced Planck constant) and Δp (momentum deviation), which arguably is meaningful not only to authors but also code consumers.

⊗ may seem foreign to most Physics undergraduates, but its meaning is no doubt *universal* among quantum technology practitioners.

I appreciate if anyone could provide an example or scenario on code consumers of a quantum related Go package finding it hard to read σX as the Pauli X matrix or ⊗ as the tensor product.

In other words, within a specific domain, judiciously chosen special symbols actually help code readability.

Sorry if I may sound a bit absurd or combative (I'm sincerely not), but I am just believing that laying out concrete details and examples helps make decisions whether pro or con.

[robert engels]

I agree - if you already allow non-ascii symbols - what’s the difference. It’s up to the owner of the code base to decide if it works better for them or not.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/39e212d7-a5d1-438f-8116-8e929b835da4n%40googlegroups.com.

[Jan Mercl]

On Wed, Oct 1, 2025 at 5:32 PM robert engels <ren...@ix.netcom.com> wrote:

> I agree - if you already allow non-ascii symbols - what’s the difference. It’s up to the owner of the code base to decide if it works better for them or not.

Non-ASCII symbols are not allowed in Go identifiers. Non-ASCII letters
are. That's the difference.

[Dan Kortschak]

On Wed, 2025-10-01 at 08:24 -0700, awaw...@gmail.com wrote:
> In fact, I use the ancient Vim editor (without any plugins) as I'm
> old fashioned, and Vim doesn't seem to have issues searching for "⊗".
> I suppose the search experience is even better in VSCode or github.

I'm not referring to search within an editor, but on the web. Most
search engines do poorly with single code point searches.

> Regarding the concern that:
> > symbols may be meaningful to the author, code consumers find it
> > harder.
> At present, Go supports ℏ (reduced Planck constant) and Δp (momentum
> deviation), which arguably is meaningful not only to authors but also
> code consumers.
> ⊗ may seem foreign to most Physics undergraduates, but its meaning is
> no doubt *universal* among quantum technology practitioners.

Mathematical symbols are not namespaced and extremely heavily
overloaded.

> I appreciate if anyone could provide an example or scenario on code
> consumers of a quantum related Go package finding it hard to read σX
> as the Pauli X matrix or ⊗ as the tensor product.
> In other words, within a specific domain, judiciously chosen special
> symbols actually help code readability.

And, "within a specific domain" is the key concern here.

>
> Sorry if I may sound a bit absurd or combative (I'm sincerely not),
> but I am just believing that laying out concrete details and examples
> helps make decisions whether pro or con.

We have a model where this has been done, Julia. Spelunking Julia code
is a nightmare because of they allow this kind of thing. Good for
small, throw-away code-bases, not so much for large long lived ones.

[Daniel Lockhart]

How do you handle whether a symbol identifier is public or private?

To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/EE71219E-FF34-42BB-BAFF-1D516EDC7DF8%40ix.netcom.com.

[Axel Wagner]

On Wed, 1 Oct 2025 at 22:06, Daniel Lockhart <d.f.l...@gmail.com> wrote:

How do you handle whether a symbol identifier is public or private?

The same as if you use a language that doesn't have case (like Chinese). The conventional solution in those languages is to prefix exported identifiers with X (perhaps from "eXported"), as I understand it.

FWIW I fully agree with Dan. I do like that Go allows arbitrary letters in identifiers. And I do quite frequently use δ or ε in my code. But only, if it is *my* code that is guaranteed not to be inflicted on anyone else. It is cute and *I* can easily type and read it and it reads better to me than "delta" or "epsilon". But that is outweighed by the downside of other people having to copy-paste symbols around when trying to collaborate or use my library.

I don't think there is a technical reason why expanding beyond letters and digits (and _) would be hard or unreasonable - with some limitations, of course, as you still need to be able to lex. But making a language requires drawing lines and where to draw those lines is subjective.

And for what it's worth: one relatively objective argument in favour of expanding beyond ASCII but not beyond letters is that restricting yourself to ASCII gives English a special place and is excluding a lot of other languages. Allowing letters is anti-discriminatory on a level that allowing symbols isn't.

 

To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/7f185c31-b69e-460f-92c8-65cfab845d39%40gmail.com.

[awaw...@gmail.com]

Thanks everyone for sharing your thoughts.

I think these are fair concerns (I hated C++'s operator overloading, which is a similar yet different issue).

In particular, thanks for pointing out Julia.

I heard that Julia is pretty popular among scientists, even though I haven't used it before.

I will try to get a feel of Julia's experience with Math symbols, and compare with the issue here.

[Amnon]

It is an interesting proposal.

It would allow us to write stuff like

func foo() {
    a := 1
    b := 1
    a+b := 3 // defining a new viable called a+b - this is OK because mathematical symbols can now be included in identifiers
    fmt.Printf("%d+%d = %d\n", a, b, a+b)
    // Output: 1+1 = 3
}

[Axel Wagner]

On Thu, 2 Oct 2025 at 07:40, Amnon <amn...@gmail.com> wrote:

It is an interesting proposal.

It would allow us to write stuff like

func foo() {
    a := 1
    b := 1
    a+b := 3 // defining a new viable called a+b - this is OK because mathematical symbols can now be included in identifiers
    fmt.Printf("%d+%d = %d\n", a, b, a+b)
    // Output: 1+1 = 3
}

To be clear, the suggestion is to include the unicode block "mathematical symbols". It does not contain a +, precisely because ASCII already provides one (which Go uses as an operator). So, no, this would not actually work.

 

To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/83a74d2a-bb94-4e2a-8a13-e5d135f4031cn%40googlegroups.com.

[Axel Wagner]

Though if you look through the list, you'll find other, similarly problematic symbols. Like division slash ∕ and asterisk operator ∗.

[Jan Mercl]

On Thu, 2 Oct 2025, 08:19 'Axel Wagner' via golang-nuts,
<golan...@googlegroups.com> wrote

> To be clear, the suggestion is to include the unicode block "mathematical symbols". It does not contain a +, precisely because ASCII already provides one (which Go uses as an operator). So, no, this would not actually work.

Unicode: Hold my beer. https://www.compart.com/en/unicode/U+FF0B

[Axel Wagner]

TIL. I thought I’ve read it didn’t. I remembered wrongly, apologies.