On Wed, 1 Oct 2025 at 22:06, Daniel Lockhart <[email protected]> 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, [email protected] <[email protected]>
> <[email protected]> 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, [email protected] 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 [email protected].
> 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 [email protected].
> 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 [email protected].
> 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 [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFZG-7GHTPaft1Qnzvtq9T_cV8L9aAZxFvmMm8yy-QKJQ%40mail.gmail.com.

Reply via email to