First of all, thank you for taking your time to answer this topic. I
know some stuff i say is dumb, i appreciate your patience.

To answer your question: i would assume that OR is about as useful as

type Constraint interface {
   Sequence && !Channel

With that said. So far i'm only a theorist and you are probably the
best expert in this field, so I would rather listen to what you have
to say than express my own ideas, even though they are not really my
own and credit has to go to other people.

I get it, there is a scope for generics and you are asking this
question because there are other considerations about the scope,
usefulness, timeline and this is a problem with more than one factor
and all factors have to be considered. I hope generics version 1 will
be received very well, and I'm actually sure they will.

I absolutely trust your judgement on this matter, of course I don't
have practical experience with generics in Go, but I saw something
that I didn't like. I'll let someone who applied generics in the field
to provide practical feedback and I will be glad to hear that they are
amazing. Sorry for wasting your time. This is undoubtedly an
improvement to the language and it is very needed. Good luck.

>I've tried to outline what we need from generics in

Right. I must have read this too, but probably a year ago and forgot
about it. This all makes sense now. Thank you very much.

чт, 23 июл. 2020 г. в 09:16, Ian Lance Taylor <i...@golang.org>:
> 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.
> Ian

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