On Wed, Jul 22, 2020 at 9:41 PM Aleksey Tulinov
<aleksey.tuli...@gmail.com> wrote:
> This is Java-style inheritance. It isn't bad, but i think that
> C++-style composition is somehow more in the spirit of Go. Strictly
> personal opinion of course. Older proposal described constraints as
> expressions, so to me it appears superior because I could potentially
> write an expression I want without asking for more features to be
> added into the compiler.
> Although i'm no longer sure if I understand what Go generics are
> supposed to do. You have the point that it's probably for a specific
> purpose, generic types something something, i don't know, but it
> probably isn't supposed to do what C++ concepts can do. Maybe i'm just
> spoiled.
> If this gets us to where we want to be - that's great, I'm happy if
> you're happy. It just doesn't feel quite right and i feel like this
> proposal could benefit from discussion on composition and stuff like
> that.

There is no question that the older syntax was more powerful.  And I
suspect that your syntax is also more powerful.  But we got extensive
feedback that the approach was too complex.  C++ and Go have very
different tolerances for complexity.

You raised the possibility of a constraint that permits either
constraintA or constraintB.  I think that supporting that kind of
constraint would be more powerful than what the current design draft
provides.  But is it a necessary feature?  How often does one want to
use such a constraint?

I've tried to outline what we need from generics in
https://blog.golang.org/why-generics.  I think that that describes the
minimum set of required features for a viable language change.  The
possibility of alternative constraints is not in that set.  Supporting
everything we can think of is not a goal.  It's not an inherently bad
thing.  But anything more powerful than the minimum set has to not
make the language more complicated to understand.

Within that context, I think it's a great idea to discuss composition
or inheritance.  If we can come up with something that is more
powerful and less complex, that would be great.


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 

Reply via email to