Sorry, I wasn't clear in my last post.
> 1. There's no implicit conversion between a value type and an interface,
and constraints would make this possible, but i feel that it's at the
expense of making the language unnecessarily complicated. Can we not just
think through our design of our applications to either prevent this need or
ensure that we build a slice of interfaces?
Here i was suggesting that constraints might not be needed as we can use
interfaces:
// Without generics
func Stringify(s []Stringer) (ret []string) {
for _, v := range s {
ret = append(ret, v.String())
}
return ret
}
// With Constraints in generics
func Stringify(type T Stringer)(s []T) (ret []string) {
for _, v := range s {
ret = append(ret, v.String())
}
return ret
}
> 2. Being able to constrain on comparable values (using <,>,==,!=).
Couldn't we create an interface which declares what we need (LessThan,
MoreThan, etc)? I feel that if the language goes down this path, why not do
the whole shebang and have operator overloading in go?
Here i was suggesting that constraints isn't necessary when trying to
compare two values, instead just use generics on interfaces:
// Without constraints
type LessThaner(type T) interface {
LessThan(T) bool
Get() T
}
func Smallest(type T)(s []LessThaner(T)) T {
smallest := s[0].Get() // panics if slice is empty
for _, t := range s[1:] {
if t.LessThan(smallest) {
smallest = t.Get()
}
}
return smallest
}
// With constraints in type list
func Smallest(type T constraints.Ordered)(s []T) T {
r := s[0] // panics if slice is empty
for _, v := range s[1:] {
if v < r {
r = v
}
}
return r
}
So my main argument is that constraints add an unnecessary dimension to
generics, and it might be better to try and avoid them.
(apologies if this post appears twice, i posted a reply but nothing
appeared after an hour)
- Ankur
On Monday, June 22, 2020 at 9:53:36 PM UTC+1 Ian Lance Taylor wrote:
> On Mon, Jun 22, 2020 at 1:41 PM Ankur Agarwal <aka...@gmail.com> wrote:
> >
> > I like the idea of generics, and having played around with them it
> definitely feels worth bringing into Golang. But, I agree with the author
> of this post and I don't think constraints on generics is needed.
> >
> > I do understand the arguments that:
> > 1. There's no implicit conversion between a value type and an interface,
> and constraints would make this possible, but i feel that it's at the
> expense of making the language unnecessarily complicated. Can we not just
> think through our design of our applications to either prevent this need or
> ensure that we build a slice of interfaces?
> > 2. Being able to constrain on comparable values (using <,>,==,!=).
> Couldn't we create an interface which declares what we need (LessThan,
> MoreThan, etc)? I feel that if the language goes down this path, why not do
> the whole shebang and have operator overloading in go?
> >
> > I've yet to really feel the need for either of these (although i'm not a
> veteran golang dev -- only 1 year with golang in a professional
> environment), but I have come across scenarios where generics would
> otherwise be useful... (and function overloading, but that's a whole
> different kettle of fish)
> >
> > It's great that we've been given the chance to give some feedback :)
>
> I'm sorry, I'm not sure quite what you are saying. The reason for
> constraints is to create a contract between the generic function and
> its caller, so that far away code doesn't break unexpectedly. See
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#constraints
> .
>
> Are you talking about type lists, rather than constraints?
>
> 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/92aaef26-2aa5-406d-a8a7-354525f411b4n%40googlegroups.com.
