'const' could be fine too. I guess this is mostly a matter of personal preference.
Regarding the array length syntax. It does require qualifying for two reasons: 1. Unnamed arguments. 2. Using 'gen' (or 'type', 'const') makes it easy to say "gen is not allowed in the return types", which is an important rule. Without qualification, this rule would be hard to express. On Mon, Jun 3, 2019, 15:26 Martin Schnabel <m...@mb0.org> wrote: > Hi Michal, > > I would argue that the 'const' keyword would by more correct. Because > the array length is and needs to be constant anyway. And it has > currently no valid meaning in a parameter list, just like with > the 'type' keyword. However i would argue that the array length, if > written as part of the array syntax, as in '[n]elem' does not need an > explicit keyword qualifier, because - again - it's unambiguous in the > parameter context. Would you agree? > > Best regards > Martin > > On 03.06.19 14:20, Michal Strba wrote: > > Hi Martin. > > > > The proposal adds types as "values", but not really. You can only accept > > a type to a function, but you cannot return a type. That makes the > > system far from a dependent type system, even with the support for > > generic array lengths. > > > > Being able to return types from functions and use those functions in > > types is what brings all the power (and complexity) of dependent typing, > > but what I proposed is just a simple system for explicit type anotation > > directly in the function signature. > > > > Regarding the 'gen' keyword, I chose it because I propose not only > > generic types, but also generic array lengths. But you are right that > > using 'type' would probably be better. Do you think that using the > > 'type' keyword also in the context of generic array lengths would be > fine? > > > > On Mon, Jun 3, 2019, 12:53 Martin Schnabel <m...@mb0.org > > <mailto:m...@mb0.org>> wrote: > > > > Hi, > > > > is my impression correct, that this proposal adds types as values to > > the > > language? It's seems like it does the section 'Unnamed generic > > arguments'. That by itself would go a long way and warrants some > > discussion, I'd say. > > > > If so, then why use a new keyword 'gen'? Why not 'type' itself. > > It would have some symmetry with how the func and struct keywords are > > used for closures and unnamed structs. The 'type' keyword has no > > possible meaning in the parameter list currently. > > > > I use the 'gen' keyword a lot as identifier, mostly for generators > > and generated code. While nobody can claim to use 'type'. This would > > make converting code so much easier, if this proposal is accepted. > > > > Just a though. Please tell me whether this would be possible. > > > > Thanks for your work, it's much appreciated. > > Martin > > > > > > On 30.05.19 14:08, Michal Strba wrote: > > > Hi Gophers! :) > > > > > > I've been thinking about generics in Go 2 ever since the original > > > contracts proposal and few days ago, ideas finally clicked. One > > of the > > > main things about this proposal is that it deliberately omits the > > > ability to restrict the set of types a function can work with. > > This is a > > > limitation, but I hope to convince you that we can still do a vast > > > majority of the things we were missing, when we were missing > > generics. > > > > > > I'd love to share my proposal with you and engage in a good faith > > > conversation. > > > > > > Link to the proposal. > > > <https://gist.github.com/faiface/e5f035f46e88e96231c670abf8cab63f > > > > > > > > Here's what the proposal covers: > > > > > > 1. Syntax of a new gen keyword. > > > 2. Generic functions. > > > 3. Unnamed generic arguments (a.k.a. a way to gve a type to the > > built-in > > > newfunction). > > > 4. Semantics of generic values (ability to use them as map keys, > > ...). > > > 5. Generic array lengths. > > > 6. Reflection and interface{}. > > > 7. Generic types (with two examples: Listand Matrix). > > > 8. Generic methods and their limitations due to reflection. > > > 9. Generic interfaces. > > > 10. List of things this proposal can't do. > > > > > > Thanks, > > > faiface > > > > > > -- > > > 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 > > <mailto:golang-nuts%2bunsubscr...@googlegroups.com> > > > <mailto:golang-nuts+unsubscr...@googlegroups.com > > <mailto:golang-nuts%2bunsubscr...@googlegroups.com>>. > > > To view this discussion on the web visit > > > > > > https://groups.google.com/d/msgid/golang-nuts/6f5f0785-93f7-475a-991c-fc919c5e6730%40googlegroups.com > > > > > > > < > https://groups.google.com/d/msgid/golang-nuts/6f5f0785-93f7-475a-991c-fc919c5e6730%40googlegroups.com?utm_medium=email&utm_source=footer > >. > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > > 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 > > <mailto:golang-nuts%2bunsubscr...@googlegroups.com>. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/golang-nuts/739d147e-162d-14fc-a13a-9e7962f074e2%40mb0.org > . > > For more options, visit https://groups.google.com/d/optout. > > > > -- > > 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 > > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/golang-nuts/CAO6k0ut8W8STeA6_AadA9FbL7HxkVimKMfMT3bTBtxDyP1N5_w%40mail.gmail.com > > < > https://groups.google.com/d/msgid/golang-nuts/CAO6k0ut8W8STeA6_AadA9FbL7HxkVimKMfMT3bTBtxDyP1N5_w%40mail.gmail.com?utm_medium=email&utm_source=footer > >. > > For more options, visit https://groups.google.com/d/optout. > > -- > 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/068a6b44-4c52-73fc-9ac7-fe46b4cdbe1d%40mb0.org > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAO6k0usVH6GMsqu%2BpDJ%2BOfeTnF0XDZq-RK_DKW5kxXRkEHsUmA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
