On Thu, Jul 23, 2020 at 1:12 AM Aleksey Tulinov
<aleksey.tuli...@gmail.com> wrote:
> 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.

I appreciate the comments.  It's not at all a waste of time.  Thanks
for writing.


> чт, 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