I am trying to add my 2 cents here.
I am sorry if my opinions have been mentioned. I personally prefer Round Brackets (parentheses). It is not about readability on symbols, but the way how I understand the logic of Type Parameters. I see Type Parameters as a way to describe how to "instantiated" a Declaration (Func/Struct) for being used. Considering the case of https://go2goplay.golang.org/p/JjA67w8ZvFu , the func `min` is asking for a `type` argument to be specified so it can work properly. Which means it is valid to code line L19 `m := min(int)` to initialize the func `min` with type `int`. If we try to read a Type Parameterized func declared in this way, it means the func `min` will first take a `type` argument to initialize it. then the second Round Brackets `(...)` put the arguments to call the func. However with Square Bracket, L19 of the case will not work, cause `m := min[int]` would mean taking an element from `min` on index `int`. (sure, min here is a Type Parameterized Func, not a slice) On the other hand, we can take an analogy of how Functional Programming (FP) works with funcs with multi parameters. (correct me if I am wrong). In FP, when a function take two arguments, say `f(a int, b string)`, it's actually interpreted as "A function called `f`, it will first take an argument `a` with type `int`, and return a function f2 which keep a copy of `a` and takes an argument `b` with type `string`". An example in Go is following: ```go func concat(a int, b string) string {} ``` is equal to ```go func concat(a int) (func( b string) string){ return func(b string) { a := a // DO THE ACTUAL WORK return } } ```` and when calling `concat()` with `concat(1, "2")`, is actually `concat(1)(2)` or `tmp := concat(1); result := tmp(2)` Taking this analogy back to the original Type Parameters proposal. We can think of a Type Parameterized func has to be called with a `type` being specified. The Type Parameterized func will return a typed version of it. Then we call it with the actual argument(s). With Square Brackets, it cannot be interpreted in this way IMO as the syntax is inconsistence. It only make it easier to read for declaring a Type Parameterized func, but not easier to make an instance of the func with type. On Saturday, August 8, 2020 at 12:02:51 PM UTC+2 Denis Cheremisov wrote: > > Have the authors considered the implications of requiring the `type` > keyword to use a generic type, not just at declaration time? Would this > open up more syntax possibilities, such as `var x T<type int>`? This might > be easier to read at the expense of five more characters of typing. It also > could unify declaration and usage syntax even more than the proposal. > > > This might be easier to read > > Square brackets are easier to read. They are larger and catchier to eyes > than lesser and greater signs used as brackets. And type-less syntax with > mandatory constraint is even easier and feels like a great match with the > rest of the language. > > > четверг, 6 августа 2020 г. в 22:25:19 UTC+3, Red Daly: > >> Have the authors considered the implications of requiring the `type` >> keyword to use a generic type, not just at declaration time? Would this >> open up more syntax possibilities, such as `var x T<type int>`? This might >> be easier to read at the expense of five more characters of typing. It also >> could unify declaration and usage syntax even more than the proposal. >> >> (Personally, I will accept any syntax. It's not realistic to expect this >> for go2, but I would prefer if go3 ditched the C-style syntax altogether in >> favor of a simpler, lisp-style syntax. Such a syntax would make it easier >> to introduce language features like this one. Macros and metaprogramming >> would also be much more straightforward for users to add useful >> abstractions to the language.) >> On Thursday, August 6, 2020 at 7:15:08 AM UTC-7 Mike Schinkel wrote: >> >>> Hi Russ, >>> >>> In general, I think the proposal is a really good one. I like that you >>> abandoned contracts as interfaces were just too similar, and personally I >>> like the choice of square brackets. >>> >>> There are a few aspects I do not like — 1.) no zero value and 2.) lack >>> of covariance and contravariance — but perhaps those can be addressed in >>> the future? >>> >>> All in all, I think the team has come up with a really good approach to >>> generics, much better than the prior proposals. >>> >>> -Mike >>> >>> P.S. If there is one thing that piqued my interest about this thread it >>> was Geoff Speicher's suggestion of a "generic" keyword, assuming type >>> inference could be addressed. That approach would be even easier to reason >>> about than the current proposal, I think. That said, the current proposal >>> is very good if type inference can not be addressed in Geoff Speicher's >>> suggestion. >>> >>> On Wednesday, July 22, 2020 at 8:02:55 PM UTC-4 Russ Cox wrote: >>> >>>> So it sounds like everyone is in favor of the entire generics proposal >>>> and all the semantics, and all we have left to hammer out is the bracket >>>> characters? Do I have that right? >>>> >>>> Best, >>>> Russ >>>> >>>> >>>> >>>> -- 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 on the web visit https://groups.google.com/d/msgid/golang-nuts/479c65b2-e2b3-41d2-a543-5b8431c79ac9n%40googlegroups.com.
