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.
