[go-nuts] A proposal for generic in go

[Marcus Yip]

On Tuesday, June 21, 2016 at 2:56:01 PM UTC-4, Axel Wagner wrote: The issue
is, that a "KeyValuePair" (no matter if you implemented it via generics
or like you mention via interfaces) i

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] A proposal for generic in go

[Alex Bligh]

On 21 Jun 2016, at 19:55, 'Axel Wagner' via golang-nuts 
 wrote:

> The issue is, that a "KeyValuePair" (no matter if you implemented it 
> via generics or like you mention via interfaces) is a fundamentally useless 
> type and generics encourage people to add useless types. A "KeyValuePair V>" is a "struct { Key K, Value V }", plain and simple. It's not an interface 
> and it's not a generic type, it's simply a struct.
> 
> I agree, that generics are useful, but they seem to be mainly useful for 
> people who write "frameworks", not so much for people who write 
> "applications" and so far, go is pretty much a language for the latter. 
> Whenever people try to justify generics, they do it from a "I want to write a 
> framework" POV - and whenever I miss generics, I do because I'm currently 
> writing a framework of some kind.

Not sure that's fair.

For background, I'd quite like generics and liked Ian's last proposal quite a 
bit, but I also appreciate the cleanliness of go.

An recent example, in an real life application, where generics would have been 
useful is as follows.

I had a cache type thing built around a red-black tree, or more precisely two 
red black trees. The items were structs, and I needed one RB tree to be ordered 
by time of insertion (then key, for uniqueness), and one by key. One red-black 
tree dealt with expiries, and one with finding the item. In the absence of 
generics, I needed to embed the struct in a 'ByTime' and 'ByItem' struct, each 
of which implement a different 'LessThan' method. And everything that accessed 
the trees had a bunch of ugly casting from an interface{} to the relevant type. 
This does not make for readable code in any form. A RB tree that was 
implemented as a generic (and perhaps took a 'LessThan' function as a lambda) 
would have been far far cleaner in *my* code.

So saying it's all about being useful for people who write "frameworks" is 
unfair. It would actually have made the application code (i.e. the library 
user) far easier to read.

Of course it's possible to generate foolish uses (I would however note in 
passing that even with KeyValuePair things might not be as simple as you think, 
as it would (presumably) require comparability of K type items); however, it's 
also possible to perform stupidity with existing go syntax. The question is 
whether generics encourage it.

-- 
Alex Bligh




-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] A proposal for generic in go

[Micky]

I guess that's for diplomatic reasons. If you watch talks of core
contributors then I believe you'll know what I mean :)

On Tue, Jun 21, 2016 at 5:15 AM, Rodrigo Kochenburger  wrote:
> Micky, I'm not sure where you're quoting from but they never said it's never
> gonna happen.
>
> From the FAQ: "Generics may well be added at some point." and "This remains
> an open issue".
>
> https://golang.org/doc/faq#generics
>
>
> On Mon, Jun 20, 2016 at 4:54 PM Micky  wrote:
>>
>> It's never going to happen! To quote the powers-to-be, "The language is
>> done".
>> Good luck!
>>
>> On Wed, Jun 15, 2016 at 6:04 AM, xingtao zhao 
>> wrote:
>> > Here is my proposal for generic in go:
>> >
>> > https://docs.google.com/document/d/1nO7D15c2B3eq2kF62C0yUs_UgpkyPL2zHhMAmlq1l98/edit?usp=sharing
>> >
>> > Many parts has not been finished, and just initial thoughts. In the
>> > proposal, I want to keep back compatibility. And I try to add the
>> > orthogonal
>> > feature only and keep the language still simple enough.
>> >
>> > Please add your comments on it. Hope it is useful and could inspire some
>> > new
>> > features in go 2.0
>> >
>> > Thanks!
>> >
>> > --
>> > 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.
>> > 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] A proposal for generic in go

[Rodrigo Kochenburger]

Micky, I'm not sure where you're quoting from but they never said it's
never gonna happen.

>From the FAQ: "Generics may well be added at some point." and "This remains
an open issue".

https://golang.org/doc/faq#generics


On Mon, Jun 20, 2016 at 4:54 PM Micky  wrote:

> It's never going to happen! To quote the powers-to-be, "The language is
> done".
> Good luck!
>
> On Wed, Jun 15, 2016 at 6:04 AM, xingtao zhao 
> wrote:
> > Here is my proposal for generic in go:
> >
> https://docs.google.com/document/d/1nO7D15c2B3eq2kF62C0yUs_UgpkyPL2zHhMAmlq1l98/edit?usp=sharing
> >
> > Many parts has not been finished, and just initial thoughts. In the
> > proposal, I want to keep back compatibility. And I try to add the
> orthogonal
> > feature only and keep the language still simple enough.
> >
> > Please add your comments on it. Hope it is useful and could inspire some
> new
> > features in go 2.0
> >
> > Thanks!
> >
> > --
> > 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.
> > 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.
> 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.
For more options, visit https://groups.google.com/d/optout.