Sorry, i wasn't very clear in my first 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 talking about constraints and I think that it isn't needed:
// Without generics
func Stringify(s []Stringer) (ret []string) {
for _, v := range s {
ret = append(ret, v.String())
}
return ret
}
// With constraints on 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 instead of type lists in constraints, I am suggesting that we can
create an interface when we need to make things comparable:
// This I feel is easier to understand
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
}
// Instead of this
type Ordered interface {
type int, int8, int16, int32, int64,
uint, uint8, uint16, uint32, uint64, uintptr,
float32, float64,
string
}
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
}
In general constraints add another dimension of complexity that I feel is
not needed.
- Ankur
On Monday, 22 June 2020 at 21:53:36 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/f7a6400e-e4fd-40b2-9fa8-b4207d66ac0fn%40googlegroups.com.
