[go-nuts] Re: Go 2 generics counterproposal: giving up restricting types

[alanfo]

Michal,

Without wishing to over-complicate your proposal, I think you should at 
least consider adding "gen int" to the mix.

The reason I say this is because the integer types support a lot more 
operators than the floating point and complex types do, namely:

1. The remainder operator (%).

2. The bitwise operators (&,|, ^, &^).

3. The shift operators (<<, >>).

4. String conversion (using string(x)).

Also integers are always ordered, whereas complex types are not, and are 
subject to overflow which is something floating point types never do, 

So having both 'num' and 'int' would give you better coverage of the 
available operators and often times you only want a generic function to 
operate on integer types anyway.

Alan


-- 
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/4ed89f89-ff3e-4e27-bee1-1b8b42608f62%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go 2 generics counterproposal: giving up restricting types

[Luis Furquim]

Hi Burak,

So, how about to change the idea to accept contracts as restrictions to
generic types?
For example:
This is defined on
https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md

contract stringer(x T) {
var s string = x.String()}


Could be expressed this way:

type stringer generic{
   contract String() string
}



Alternatively it could have multiple definitions:
This is defined on
https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md

contract adjustable(x T) {
var _ T = x.Adjust()
x.Apply()}


Could be expressed this way:

type adjustable generic{
contract (   Adjust() adjustable
   Apply())}



So, changing this way could solve this issue?

Best regard,
Luis Otávio



On Fri, Jun 7, 2019 at 12:17 PM Burak Serdar  wrote:

> On Fri, Jun 7, 2019 at 7:32 AM Luis Furquim  wrote:
> >
> >
> >
> > Hello gophers,
> >
> > I have almost no experience on language definitions/proposals and on
> generics.
> > But an idea came to my mind and I wanted to share it.
> > It is an idea, not a proposal, I haven't worked on
> detailing/elaboration, etc.
> > As stated on my gist, I got the text and examples from Faiface gist and
> adapted to my idea.
> > No plagiarism intent, just to quickly have something readable by people.
> > But, if people finds the copy/edit method I used is offensive, just
> point this and I may delete the gist.
>
>
> One problem with this type of generic types is the lack of type
> checking at the time of generic compilation. You can only type check
> the generic functions when they are instantiated and that can cause
> hard to decipher error messages. The contracts idea was promoted to
> eliminate those.
>
> >
> > So, here is the gist:
> > https://gist.github.com/luisfurquim/548c37870f7ed5a57a1f91a696cfc62f
> >
> > Best regards,
> > Luis Otavio
> >
> >
> > Em quinta-feira, 30 de maio de 2019 13:29:03 UTC-3, Michal Strba
> escreveu:
> >>
> >> 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.
> >>
> >> 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 new function).
> >> 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: List and 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.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/d284f74d-1e2c-474e-bc0d-a30413d17d98%40googlegroups.com
> .
> > For more options, visit https://groups.google.com/d/optout.
>


-- 
Luis Otavio de Colla Furquim

-- 
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/CACyQ4W6LasZnem6qJqmJfpRFX%2BP_CesMyUfXqTr7%2BMOrshnqzQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go 2 generics counterproposal: giving up restricting types

[Burak Serdar]

On Fri, Jun 7, 2019 at 7:32 AM Luis Furquim  wrote:
>
>
>
> Hello gophers,
>
> I have almost no experience on language definitions/proposals and on generics.
> But an idea came to my mind and I wanted to share it.
> It is an idea, not a proposal, I haven't worked on detailing/elaboration, etc.
> As stated on my gist, I got the text and examples from Faiface gist and 
> adapted to my idea.
> No plagiarism intent, just to quickly have something readable by people.
> But, if people finds the copy/edit method I used is offensive, just point 
> this and I may delete the gist.


One problem with this type of generic types is the lack of type
checking at the time of generic compilation. You can only type check
the generic functions when they are instantiated and that can cause
hard to decipher error messages. The contracts idea was promoted to
eliminate those.

>
> So, here is the gist:
> https://gist.github.com/luisfurquim/548c37870f7ed5a57a1f91a696cfc62f
>
> Best regards,
> Luis Otavio
>
>
> Em quinta-feira, 30 de maio de 2019 13:29:03 UTC-3, Michal Strba escreveu:
>>
>> 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.
>>
>> 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 new 
>> function).
>> 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: List and 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/d284f74d-1e2c-474e-bc0d-a30413d17d98%40googlegroups.com.
> 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/CAMV2Rqq%2BttDYYEKfn5JjWZfNnrb0MhfTekaDnWi-4o%3D9UZiAbg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 2 generics counterproposal: giving up restricting types

[Luis Furquim]

Hello gophers,

I have almost no experience on language definitions/proposals and on 
generics. 
But an idea came to my mind and I wanted to share it. 
It is an idea, not a proposal, I haven't worked on detailing/elaboration, 
etc.
As stated on my gist, I got the text and examples from Faiface gist and 
adapted to my idea. 
No plagiarism intent, just to quickly have something readable by people. 
But, if people finds the copy/edit method I used is offensive, just point 
this and I may delete the gist.

So, here is the gist:
https://gist.github.com/luisfurquim/548c37870f7ed5a57a1f91a696cfc62f

Best regards,
Luis Otavio


Em quinta-feira, 30 de maio de 2019 13:29:03 UTC-3, Michal Strba escreveu:
>
> 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. 
> 
>
> 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 
> new function).
> 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: List and 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d284f74d-1e2c-474e-bc0d-a30413d17d98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 2 generics counterproposal: giving up restricting types

[Carl]

This proposal makes sense to me. 

Disclaimer: 
I don't know enough about language design to provide feedback on how it may 
be refined. This is just my perspective as a potential future user.

   1. It is one of the simplest proposals I've read so far (but I have not 
   read them all - there are too many to keep up with)
   2. It is easy to understand and visualise where it would be used
   3. It is orthogonal - it does not tread on the capabilities of other 
   keywords, but complements them nicely
   4. In conjunction with the "gen eq" and "gen num" keywords, it would be 
   sufficient for all the work I've needed to do



On Friday, May 31, 2019 at 4:29:03 AM UTC+12, 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. 
> 
>
> 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 
> new function).
> 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: List and 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/291fced4-873d-454f-9a23-49375cd5be6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go 2 generics counterproposal: giving up restricting types

[Raffaele Sena]

Completely agree about "Generics are useful except when their syntax
becomes cryptic". But reading this proposal (quickly, while doing a bunch
of other stuff :), the syntax is very clean and the proposal is very well
thought.


On Thu, May 30, 2019 at 10:44 AM Michal Strba  wrote:

> I agree with that. What exactly do you consider cryptic, though, about
> my proposal? I thought the syntax was very clean. Furthermore,
> regarding relating this to C++, I quote:
>
> > Just to make it clear, you aren't allowed to use operators like +, -, <,
> call methods, or access struct fields of a generic value
>
> I'm just not sure how your sentiment relates to the proposal.
>
> št 30. 5. 2019 o 19:41  napísal(a):
> >
> > Sorry again for the power failure...let me try one last time
> >
> > one of the annoying things you have to deal with as a team member is
> being assigned an "update" of code written by someone who no longer works
> for the team.
> > What makes this annoying is possibility of running into code sections
> that contain "crytic" statements that require lots of effort to understand.
> >  After looking at the link you provided, based on my history dealing
> with unnecessary and avoidable 'cryptic C++,
> >  my input  is:  Generics are a great idea EXCEPT when they allow use of
> cryptic syntax
> >
> > On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, 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.
> >>
> >> 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 new function).
> >> 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: List and 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.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/4e266f34-32d8-4b3d-8f45-55da5651ed9e%40googlegroups.com
> .
> > 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/CAO6k0usA%3D6EdH6mpTPqYnpnEBWNu8GST%2Bam-G2rQEZNPGUPC7A%40mail.gmail.com
> .
> 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/CANKfuca%2B_CYJ59nSfB8n3zq8D0acXEcfHvV3HtyQEHmZ9xnAAw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go 2 generics counterproposal: giving up restricting types

[Michal Strba]

I agree with that. What exactly do you consider cryptic, though, about
my proposal? I thought the syntax was very clean. Furthermore,
regarding relating this to C++, I quote:

> Just to make it clear, you aren't allowed to use operators like +, -, <, call 
> methods, or access struct fields of a generic value

I'm just not sure how your sentiment relates to the proposal.

št 30. 5. 2019 o 19:41  napísal(a):
>
> Sorry again for the power failure...let me try one last time
>
> one of the annoying things you have to deal with as a team member is being 
> assigned an "update" of code written by someone who no longer works for the 
> team.
> What makes this annoying is possibility of running into code sections that 
> contain "crytic" statements that require lots of effort to understand.
>  After looking at the link you provided, based on my history dealing with 
> unnecessary and avoidable 'cryptic C++,
>  my input  is:  Generics are a great idea EXCEPT when they allow use of 
> cryptic syntax
>
> On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, 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.
>>
>> 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 new 
>> function).
>> 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: List and 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/4e266f34-32d8-4b3d-8f45-55da5651ed9e%40googlegroups.com.
> 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/CAO6k0usA%3D6EdH6mpTPqYnpnEBWNu8GST%2Bam-G2rQEZNPGUPC7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 2 generics counterproposal: giving up restricting types

[lgodio2]

Sorry again for the power failure...let me try one last time

one of the annoying things you have to deal with as a team member is being 
assigned an "update" of code written by someone who no longer works for the 
team.
What makes this annoying is possibility of running into code sections that 
contain "crytic" statements that require lots of effort to understand.
 After looking at the link you provided, based on my history dealing with 
unnecessary and avoidable 'cryptic C++,
 my input  is:  Generics are a great idea EXCEPT when they allow use of 
cryptic syntax

On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, 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. 
> 
>
> 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 
> new function).
> 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: List and 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4e266f34-32d8-4b3d-8f45-55da5651ed9e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 2 generics counterproposal: giving up restricting types

[Michal Strba]

> Generics are useful except when their syntax becomes cryptic 

I agree, are you referring to anything specific?

Dňa štvrtok, 30. mája 2019 19:29:09 UTC+2 L Godioleskky napísal(-a):
>
>
>
> On Thursday, May 30, 2019 at 1:24:55 PM UTC-4, L Godioleskky wrote:
>>
>> one of the annoying things you have to deal with as a team member is 
>> being assigned an "update" of code written by someone who no longer works 
>> for the team. What makes this annoying is possibility of running into code 
>> sections that contain "crytic" statements that require lots of effort to 
>> understand. After looking at the link you provided my input, based on 
>> dealing with cryptic C++  is: Go should not allow cryptic syntax.
>>
> Generics are useful except when their syntax becomes cryptic 
>  
>
>>   w
>>
>> On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, 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. 
>>> 
>>>
>>> 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 
>>> new function).
>>> 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: List and 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/042a2594-1a00-43e9-8866-86c362d9298b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 2 generics counterproposal: giving up restricting types

[lgodio2]

llow

On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, 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. 
> 
>
> 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 
> new function).
> 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: List and 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5f5ec80f-ce98-4420-9837-d0800852ced1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 2 generics counterproposal: giving up restricting types

[lgodio2]

On Thursday, May 30, 2019 at 1:24:55 PM UTC-4, L Godioleskky wrote:
>
> one of the annoying things you have to deal with as a team member is being 
> assigned an "update" of code written by someone who no longer works for the 
> team. What makes this annoying is possibility of running into code sections 
> that contain "crytic" statements that require lots of effort to understand. 
> After looking at the link you provided my input, based on dealing with 
> cryptic C++  is: Go should not allow cryptic syntax.
>
Generics are useful except when their syntax becomes cryptic 
 

>   w
>
> On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, 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. 
>> 
>>
>> 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 
>> new function).
>> 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: List and 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/168e423b-eb56-4c2c-8222-567756146dbc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 2 generics counterproposal: giving up restricting types

[lgodio2]

one of the annoying things you have to deal with as a team member is being 
assigned an "update" of code written by someone who no longer works for the 
team. What makes this annoying is possibility of running into code sections 
that contains "crytic" statements that require lots of effort to 
understand. After looking at the link you provided my input, based on 
dealing with cryptic C++  is:
  w

On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, 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. 
> 
>
> 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 
> new function).
> 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: List and 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6ef558bc-f66d-409e-bb78-7e40360e7a55%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.