[Groxx]

To hoist this comment a bit higher: https://news.ycombinator.com/item?id=29583557 and this one which as the "a hah" moment for me: https://news.ycombinator.com/item?id=29583866

While you can't do this:

    type Option[T any] struct{}
    func (o Option[T]) Map[U any](f func(a T) U) Option[U] { ... }

You can do this:

   type Option[T,U any] struct{}
   func (o Option[T,U]) Map(f func(a T) U) Option[U] { ... }

So this is not quite as restricting as it seems. Though it is still likely to be annoying. Runnable example: https://gotipplay.golang.org/p/2w2y1KEjXVE

[rawoke083600]

> func (o Option[T,U]) Map(f func(a T) U) Option[U] { ... }

I love GO and it's simplicity and yes I do want generics, but is it just me or is this reading much much harder now ? It reminds me of those ugly voidfuncptr signatures of C and C++ :(

Maybe my eyes should just get used to it but I do feel a little my simple Go now reads not as easy. YMMV

[tgv]

Personally, I think that Rust's Option and Result are not well suited to Go. Option may serve a purpose, but the language was not built around these constructs. It's best (still IMO) to use generics to avoid code repetition, not to build semi-mathematical abstractions for their own sake right now. With time, we'll know how to use generics properly.

[Groxx]

Without generics this is

    func (o IntToStringOption) Map(f func(a int) string) IntToStringOption { ... }
    // ... but that has to be repeated dozens of times

tbh I don't see it as much different. The func argument is the most complex part of the whole thing. And much of the readability comes from not using single-char type names, but you do learn to see past that with time.

[jchw]

You should also be able to do functions instead of methods, just downgrading the receiver to a normal parameter, if I understand correctly. Other than losing the method call syntax, this is probably the most reasonable workaround, due to the interface problem discussed in the generics proposal.