I like all points in the draft change.
My 2 cents around the any alias would be that it shouldn't be a problem. I
don't think people are suddently going to start overusing it, since using
vaues of type `interface{}` is extremely tedious in Go, and that won't
magically change if the type is shorter by a few characters.
One thing that might be of concern regarding using type lists in interfaces
is that, if that is allowed outside of generics, then it should be decided
beforehand whether a type switch over such values is exhaustive or not. I
don't think it will be a breaking change if it is exhaustive for such
interfaces, but if it isn't, then changing it later would be. For the
record, I think it should b exhaustive.
On Friday, August 21, 2020 at 8:15:46 PM UTC+2 bbse...@gmail.com wrote:
> On Fri, Aug 21, 2020 at 11:01 AM 'Carla Pfaff' via golang-nuts
> <golan...@googlegroups.com> wrote:
> >
> > On Friday, 21 August 2020 at 16:46:22 UTC+2 bbse...@gmail.com wrote:
> >>
> >> All constraints except "any" specify a constraint for the type. A
> >> Stringer constraint will ensure that the type has String() string
> >> method. "any" is a lack of constraint.
> >
> >
> > The empty interface / any is a constraint that ensures that the type has
> at least 0 methods and all of these 0 methods must match the 0 methods of
> the interface. An empty purse is still a purse, an empty constraint is
> still a constraint.
> >
> >>
> >> My problem is the attractiveness of "any" as a return type.
> >
> >
> > I don't see why anybody would find it attractive as a return type.
> People don't use the empty interface because they like it so much, but
> because Go doesn't have parametric polymorphism / "generics" yet. There are
> many programming languages that have a named top type and it is rarely
> abused. Programmers want to write type safe code if they can.
>
> I disagree. Especially people coming from other languages with a
> strong emphasis on DRY tend to overuse interface{}, many times
> incorrectly, and generics will not fix that. "any" will make it more
> attractive, because it no longer looks like an interface. I agree that
> this is a hypothetical problem at this point without any actual
> complaints from developers. But defining an alias "any" is easy if you
> need it. Providing one predefined is endorsing its use.
>
> >
> > --
> > 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...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/8e5b46ba-7a3e-4d55-ac97-1e70d06e622dn%40googlegroups.com
> .
>
--
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/4245d27a-fcc6-438d-8b6d-d1ba44eb18c3n%40googlegroups.com.
