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
}
On Thursday, 2 October 2025 at 03:35:52 UTC+1 awaw...@gmail.com wrote:
> 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.
>
> On Thursday, October 2, 2025 at 4:27:28 AM UTC+8 Axel Wagner wrote:
>
>> 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.
>>
>>
>>> On 2025-10-01 11:31, robert engels 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.
>>>
>>> On Oct 1, 2025, at 10:24 AM, awaw...@gmail.com <awaw...@gmail.com>
>>> wrote:
>>>
>>> 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.
>>>
>>> On Wednesday, October 1, 2025 at 3:53:54 PM UTC+8 Dan Kortschak wrote:
>>>
>>>> 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.
>>>>
>>>>
>>> --
>>> 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
>>>
>>> <https://groups.google.com/d/msgid/golang-nuts/39e212d7-a5d1-438f-8116-8e929b835da4n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>>
>>> --
>>> 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/EE71219E-FF34-42BB-BAFF-1D516EDC7DF8%40ix.netcom.com
>>>
>>> <https://groups.google.com/d/msgid/golang-nuts/EE71219E-FF34-42BB-BAFF-1D516EDC7DF8%40ix.netcom.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> --
>>> 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/7f185c31-b69e-460f-92c8-65cfab845d39%40gmail.com
>>>
>>> <https://groups.google.com/d/msgid/golang-nuts/7f185c31-b69e-460f-92c8-65cfab845d39%40gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
--
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+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/83a74d2a-bb94-4e2a-8a13-e5d135f4031cn%40googlegroups.com.
