On Tue, Jan 5, 2021 at 7:25 PM tapi...@gmail.com <tapir....@gmail.com> wrote:
> 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.) > Maybe. It would be backwards compatible. But why would you want to? `chan` being a keyword is a feature, not a bug, as I mentioned. Keywords and other delimiters serve as a signal to the parser. OP suggested to use concatenation to for type argument application and used `chan int` as an example that no separator is needed. All I was pointing out is, that comparing apples to oranges, because `chan` is a keyword that provides additional context to the parser. It might be possible to do without a separator. It might be possible to do so without parsing ambiguities. It might be possible to do without requiring unbounded lookahead. It might be possible while maintaining useful error messages and still separating the parsing from the type-checking phase (necessary for good tool workflows). I genuinely don't know if it is (and it's hard to prove a negative). All I was saying is, that a stronger argument than "it works fine for `chan int`" is needed to demonstrate that all of this is the case. 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. > I argued "if we use the same syntax for functions, readability suffers". So it doesn't matter really matter what they meant. Functions will either use the same syntax, meaning readability suffers, or functions will use a different syntax, meaning there is confusing inconsistency. It's an inescapable dichotomy: Choosing the suggested syntax for types means one of two bad outcomes. > >> >> 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 > <https://groups.google.com/d/msgid/golang-nuts/cf8e703b-bb4e-4210-8b9d-42b94f4f8e95n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAEkBMfHARj6d6Wy2jQObvMDJOgjSaiur8FefmeNaWFMRO4xTpg%40mail.gmail.com.
