On Thu, 2 Oct 2025 at 07:40, Amnon <amno...@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.
>
> 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
> <https://groups.google.com/d/msgid/golang-nuts/83a74d2a-bb94-4e2a-8a13-e5d135f4031cn%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+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEMskQEo4%2B6ZiEkG-YQH45LheNOGEF%3DMnpz0czg1bjeBQ%40mail.gmail.com.
