Generics feedback

[Calum Shaw-Mackay]

Hi all -

I know that there’s have been numerous threads regarding the syntax for declaring generic types etc, and at it’s core Go is a language that can do a lot without syntactic sugar just for the sake of it, but sometimes that syntactic sugar helps in a fundamental way - legibility.

Observe this function declaration

func Combine(type T)(s []T) (T,error){
….
}

Do we think that 3 consecutive clauses wrapped in parentheses is legible, that the intent of both the function and its constraints are easily discernible?
To me, and it is only my opinion, unless (type T) has different ‘versions’ i.e. (struct T) or (func T), isn’t "(type " not only redundant but reduces readability?

Apologies if this has been discussed before.

Calum

[Axel Wagner]

Readability, at the end of the day, is subjective.

So, personally: Yes, I absolutely find it more readable than any alternative that has been suggested. Personally, when I see code using a bunch of extra symbols that have special meaning (Perl and Haskell are extreme examples), I tend to "zone out" and find it really hard to actually make the effort of trying to parse it. I really like Go's general approach of using fewer separators and keywords to convey meaning.

But in any case: I believe over time, it will a) become clear that generic code will be less common than people think (I hope) and b) that you get used to the syntax either way. (also, yes, this has been discussed before, ad nauseam in fact :) )

--
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/6661399B-BF48-4D15-802C-E2B1C6C0F348%40gmail.com.

[Calum Shaw-Mackay]

" I believe over time, it will a) become clear that generic code will be less common than people think (I hope) and b) that you get used to the syntax either way. (also, yes, this has been discussed before, ad nauseam in fact :) )”

Yes I also hope that the need to generify everything is kept to an absolute minimum.

Apologies about discussing things already spoken about, I have arrived fairly late to this party :)

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHO0hvNKT8tVM2tXk1trDbRFqJaGH%3DWtParweJiJQNQbg%40mail.gmail.com.

[t hepudds]

Hello Calum,

One FYI that Tyler Compton pulled together a helpful list of dozen or so different alternative generics syntax suggestions along with their corresponding recent golang-nuts threads:

  https://groups.google.com/d/msg/golang-nuts/uQDrcHDwT_w/Y-Myzuw_AQAJ

  

That could be a helpful starting point, including to see what the prior response might have been from Ian Lance Taylor and others.

One link listed there that is especially worth a read is the second link in the list there, which is a longer explanation from Ian on his rationale for him personally wanting to take a "wait and see" approach on the syntax. 

For your particular example, I think it reads slightly cleaner in the Go2Go Playground:

  https://go2goplay.golang.org/p/S3Fgmgmblr0

  

The fixed-width font, the 2 extra spaces added by gofmt (compared to how you had formatted it in your post), and the 'Print' function that parallels your 'Combine' function all help at least slightly. That said, I don't personally know if the current syntax is the best syntax, but it also seems that the people who have spent the most time on the syntax are also saying they don't know if the current syntax is the best syntax and that time and more real examples are needed before really anyone will know.

In some sense, rather than you being "late to the party", you might actually be early to the party ;-)

Regards,

thepudds

On Sunday, June 28, 2020 at 8:58:56 AM UTC-4, Calum Shaw-Mackay wrote:

" I believe over time, it will a) become clear that generic code will be less common than people think (I hope) and b) that you get used to the syntax either way. (also, yes, this has been discussed before, ad nauseam in fact :) )”

Yes I also hope that the need to generify everything is kept to an absolute minimum.

Apologies about discussing things already spoken about, I have arrived fairly late to this party :)

On 28 Jun 2020, at 12:23, 'Axel Wagner' via golang-nuts <golan...@googlegroups.com> wrote:

Readability, at the end of the day, is subjective.

So, personally: Yes, I absolutely find it more readable than any alternative that has been suggested. Personally, when I see code using a bunch of extra symbols that have special meaning (Perl and Haskell are extreme examples), I tend to "zone out" and find it really hard to actually make the effort of trying to parse it. I really like Go's general approach of using fewer separators and keywords to convey meaning.

But in any case: I believe over time, it will a) become clear that generic code will be less common than people think (I hope) and b) that you get used to the syntax either way. (also, yes, this has been discussed before, ad nauseam in fact :) )

On Sun, Jun 28, 2020 at 11:16 AM Calum Shaw-Mackay <calum.s...@gmail.com> wrote:

Hi all -

I know that there’s have been numerous threads regarding the syntax for declaring generic types etc, and at it’s core Go is a language that can do a lot without syntactic sugar just for the sake of it, but sometimes that syntactic sugar helps in a fundamental way - legibility.

Observe this function declaration

func Combine(type T)(s []T) (T,error){
 ….
}

Do we think that 3 consecutive clauses wrapped in parentheses is legible, that the intent of both the function and its constraints are easily discernible?
To me, and it is only my opinion, unless (type T) has different ‘versions’ i.e. (struct T) or (func T), isn’t "(type " not only redundant but reduces readability?

Apologies if this has been discussed before.

Calum


--
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 golan...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6661399B-BF48-4D15-802C-E2B1C6C0F348%40gmail.com.

--
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 golan...@googlegroups.com.