I agree. That is a good point. I consider arrays an edge case. Although
still important, it will probably not be all too common. So the extra
verbosity should not be a problem.
I am happy you generally agree and think these minor tweaks can make a
big difference for the roll-out of the proposed feature, if accepted.
I also think, that this is one of the better proposals. It at least
feels more like go, syntax-wise, than most, except for the num part,
which seems like an afterthought.
Again thank you for your work exploring this!
Best regards
Marin
On 03.06.19 15:49, Michal Strba wrote:
'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
<mailto: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>
> <mailto: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%2bunsubscr...@googlegroups.com
<mailto:golang-nuts%252bunsubscr...@googlegroups.com>>
> > <mailto:golang-nuts+unsubscr...@googlegroups.com
<mailto:golang-nuts%2bunsubscr...@googlegroups.com>
> <mailto:golang-nuts%2bunsubscr...@googlegroups.com
<mailto:golang-nuts%252bunsubscr...@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>
> <mailto:golang-nuts%2bunsubscr...@googlegroups.com
<mailto:golang-nuts%252bunsubscr...@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%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/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
<mailto:golang-nuts%2bunsubscr...@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
<mailto: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
<https://groups.google.com/d/msgid/golang-nuts/CAO6k0usVH6GMsqu%2BpDJ%2BOfeTnF0XDZq-RK_DKW5kxXRkEHsUmA%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/11395c55-4cd4-7c35-2f39-77e49b28799a%40mb0.org.
For more options, visit https://groups.google.com/d/optout.
