On Tuesday, January 5, 2021 at 8:43:44 AM UTC-5 axel.wa...@googlemail.com wrote:
> On Tue, Jan 5, 2021 at 12:03 PM Anonymous AWK fan <awkf...@mailfence.com> > wrote: > >> Why does there need to be a delimiter, there isn't one between chan and >> int in chan int, which I think is more readable than chan[int]. >> > > `chan` is a keyword, names of generic types and functions are identifiers. > So, in a way, yes, there is a delimiter: `chan`. > Is it possible to change `chan` to a builtin identifier? (I'm uncertain on this.) > > I think most generic types would only have 1 type-parameter and the syntax >> should be like the built-in ones ([]T, *T, func(Params) Result, >> map[Key]Elem and chan T). Putting the extra ones in square brackets is the >> best thing I can think of. Also I think Graph[Node]Edge or Graph[Edge]Node >> is still readable. >> > > Readability is not a binary choice, but a matter of degree. Everything is > *somewhat* readable. But implying an asymmetry that isn't there seems > confusing to me. > > I was only suggesting this for generic types. >> > > Well, then that's another drawback. Using inconsistent syntax for generic > types and functions is confusing. > OP doesn't intend to use inconsistent syntax. I think it is just that OP hasn't got an idea on the function part yet. > > On Tue, Jan 5, 2021 at 12:43 PM Anonymous AWK fan <awkf...@mailfence.com> > wrote: > >> Axel, please send your reply to golang-nuts too, you can ignore the rest >> of this, I already sent it to you but not golang-nuts because I didn't >> reply to all. >> >> > What is the "them" to be omitted if there is only one type parameter? >> It wouldn't make sense to omit the brackets (because there needs to be some >> delimiter between the name of the generic function/type and the type >> argument). But if there is only one type-parameter anyway, I don't know >> what else you would omit. >> >> Why does there need to be a delimiter, there isn't one between chan and >> int in chan int, which I think is more readable than chan[int]. >> >> > Either way - you are using `sync.Map` to motivate this, with a clear >> analogue to `map`. But what about types that *don't* represent a map (like >> the Graph-example, where both type-parameters are on mostly equal footing)? >> >> I think most generic types would only have 1 type-parameter and the >> syntax should be like the built-in ones ([]T, *T, func(Params) Result, >> map[Key]Elem and chan T). Putting the extra ones in square brackets is the >> best thing I can think of. Also I think Graph[Node]Edge or Graph[Edge]Node >> is still readable. >> >> > And what about generic functions? I think >> > Foo[int]string(bar, baz) >> > isn't super readable, TBH. >> >> I was only suggesting this for generic types. >> > -- 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/cf8e703b-bb4e-4210-8b9d-42b94f4f8e95n%40googlegroups.com.
