Restrict general type parameter identifiers to be a single uppercase ascii letter.

[Wojciech S. Czarnecki]

I'd propose to amend specification so the type parameter identifiers were of A-Z set,
ie. single uppercase ascii letter. While it is a current convention, it would be better
to have this convention forced by compiler. First to have an additional cue "generics here",
second - to close an easy avenue to hide cloudy or malignant constructs in the source.

= induced by conversation spotted in other thread:

> Carla Pfaff via golang-nuts" <golan...@googlegroups.com> wrote:
>> m8il...@gmail.com wrote:
> On Tuesday, 19 January 2021 at 15:39:25 UTC+1 m8il...@gmail.com wrote:
>
> > Seems to me that most generics implementations use a capital letter
> > abstracted type syntax that I hate.
>
> This is just a convention and not part of the syntax, which means it's
> irrelevant to the discussion about the proposal. You can easily use
> lowercase letters/identifiers: https://go2goplay.golang.org/p/eWgJSLNTZw8

--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE

[Ian Lance Taylor]

On Tue, Jan 19, 2021 at 6:33 PM Wojciech S. Czarnecki <oh...@fairbe.org> wrote:
>
> I'd propose to amend specification so the type parameter identifiers were of A-Z set,
> ie. single uppercase ascii letter. While it is a current convention, it would be better
> to have this convention forced by compiler. First to have an additional cue "generics here",
> second - to close an easy avenue to hide cloudy or malignant constructs in the source.
>
> = induced by conversation spotted in other thread:

Personally I think this role would be better played by some sort of
linter. Reasonable people can disagree as to the naming style to use
for type parameters.

Ian

> > Carla Pfaff via golang-nuts" <golan...@googlegroups.com> wrote:
> >> m8il...@gmail.com wrote:
> > On Tuesday, 19 January 2021 at 15:39:25 UTC+1 m8il...@gmail.com wrote:
> >
> > > Seems to me that most generics implementations use a capital letter
> > > abstracted type syntax that I hate.
> >
> > This is just a convention and not part of the syntax, which means it's
> > irrelevant to the discussion about the proposal. You can easily use
> > lowercase letters/identifiers: https://go2goplay.golang.org/p/eWgJSLNTZw8
>
> --
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>

> --
> 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 on the web visit https://groups.google.com/d/msgid/golang-nuts/20210120033232.7492029f%40xmint.

[Jérôme Champion]

A bit out of subject but the naming with generics has always bothered me. It's more of an general observation and don't have a solution for it.

I think we all agree that naming types and variables is important. Why for generics we accept that naming them E, K P, T etc.. is good and sufficient?

I have always a hard time understanding signature because these one letter don't give me any context to catch on. (It work for K and V because they are common and containers are an easy concept to grasp)

Perhaps in go the generic parameters will stay close enough to not be a problem, but my experience in Java show me it's really hard to understand a hierarchy of parametrized types and function across multiple files when they all use the same letters.

And as letters have barely no meaning behind it, they generally evolve in non controlled way. Not in containers or map/reduce but in some controller where every now fancy functionality add its share of constraints it can become daunting.

In that case, using one letter just hide the mess behind it.

So while one letter work well for containers and map reduce, and that I would wish that generic is used in simple way I think it's to early to make a decision.

Hopefully if the go community doesn't go full Java style with it's generic one letter could be okay.

[Carla Pfaff]

On Wednesday, 20 January 2021 at 10:05:24 UTC+1 cham...@gmail.com wrote:

A bit out of subject but the naming with generics has always bothered me. It's more of an general observation and don't have a solution for it.

I think we all agree that naming types and variables is important. Why for generics we accept that naming them E, K P, T etc.. is good and sufficient?

Also, until now, in Go identifiers beginning with a capital letter are exported.

I personally liked the lower case identifiers they used in the Featherweight Go paper (and for type parameters in Haskell). On the other hand, I can see that many people are familiar with the T & Co. from C++ and its various derivatives.

I don't have strong feelings either way, but it may be a chance to make a better choice than other language ecosystems.

[Brian Candler]

On Wednesday, 20 January 2021 at 10:39:48 UTC Carla Pfaff wrote:

Also, until now, in Go identifiers beginning with a capital letter are exported.

Function parameters and local variables which start with a capital letter are not exported.

I think it's a matter of taste whether you write

func foo(a int) {

    b := a

    ...

}

or

func foo(A int) {

    B := A

     ...

}

I prefer the former, but the latter is not forbidden.  I can see that a convention of initial caps for type parameters would help to distinguish them visually.

[Axel Wagner]

On Wed, Jan 20, 2021 at 10:05 AM Jérôme Champion <cham...@gmail.com> wrote:

A bit out of subject but the naming with generics has always bothered me. It's more of an general observation and don't have a solution for it.

I think we all agree that naming types and variables is important. Why for generics we accept that naming them E, K P, T etc.. is good and sufficient?

I think the general rule of thumb I find agreeable is "the length of an identifier should be inversely correlated to the distance between its declaration and its use". Personally, I find code with shorter variable names easier to read (the code structure stands out more), as long as I know what the identifiers are - so I strive to keep them as short as possible, while still retaining clarity of what they are. That leads to above rule of thumb.

As type-parameters are always inherently local to the declaration they appear in (and even a method needs to mention them in the receiver), I think it can be argued that they have similar locality to function parameters and should follow similar rules.

 

Personally, that's what I intend to do. For example

* If I only use one type-parameter, it doesn't matter - `[T any]` is easy to understand and reading `T` should be clear enough

* If I have multiple type-parameters and there is enough context to distinguish them, I will use single-letter names - e.g. `[K comparable, V any]` or `[E Edge, N Node]` seem clear.

* If there is not enough context, I will name them, for documentation purposes - e.g. `[Edge, Node any]`.

Personally, I intend to use upper-case names, because I am used to consider lower-case names to be a signal that a type is not exported and would find that confusing in documentation.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9060b24f-810b-451f-bba7-42079c73ca4en%40googlegroups.com.

[Axel Wagner]

On Wed, Jan 20, 2021 at 2:27 PM Axel Wagner <axel.wa...@googlemail.com> wrote:

I think the general rule of thumb I find agreeable is "the length of an identifier should be inversely correlated to the distance between its declaration and its use".

I just realized that this is wrong. It should be correlated, not inversely correlated m(

Don't know where the "inversely" came from.

[Kevin Chadwick]

>
>> I think the general rule of thumb I find agreeable is "the length of
>an
>> identifier should be inversely correlated to the distance between its
>> declaration and its use".
>>
>

Loosely correlated, perhaps.

I'll be honest. I have always found this advice to be rarely useful. It certainly removes one of the hardest parts of programming from tiny functions and encourages their use but their use should be a consideration, in any case.

I still don't see why generic functions can't be as close as possible to standard functions.