Ian,
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
AND or NOT.
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
https://blog.golang.org/why-generics.
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
https://groups.google.com/d/msgid/golang-nuts/CAMteYTYWvtfkRo13dfE1XJyWkwK1EKfKRuQP-22dkLbObpMUwg%40mail.gmail.com.
