An argument for this is also that (all ?) languages that use generics use
<>. It might make learning just easier for new Go developers that have
experience from generics-compatible languages.
Dimas -> Resembling other languages in some ways is not necessarily a bad
thing, if the idea behind it makes sense.
Le mercredi 17 juin 2020 18:36:10 UTC+2, Charles Crete a écrit :
>
> Based on the new proposal, having the type parameters as () seems very
> confusing, as now 3 things in a row use ():
> - Type parameters
> - Function parameters/arguments
> - Return tuple
>
> This results in code like (from the draft):
> func Stringify(type T Stringer)(s []T) (ret []string) {
> for _, v := range s {
> ret = append(ret, v.String())
> }
> return ret
> }
>
> Instead, using <> similar to other languages, makes it easier to visual
> parse:
> func Stringify<T Stringer>(s []T) (ret []string) {
> for _, v := range s {
> ret = append(ret, v.String())
> }
> return ret
> }
>
> This can also apply to type definitions:
> type Vector<T> []T
>
> To summarize:
> - Having 3 times () in a row makes it confusing to visual parse
> - The type keyword is not necessary
> - Using <> would make it friendly (and easier to recognize)
>
--
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/c524fc34-6d4a-4ae3-8db9-665f48c7b866o%40googlegroups.com.
