On Tue, 23 Jun 2020 at 03:04, Ian Lance Taylor <i...@golang.org> wrote:
> On Mon, Jun 22, 2020 at 6:19 PM 移库海牙客 <redstorm....@gmail.com> wrote:
> >
> > I agree the syntax should be more readable and easier to understand. But
> I think the current syntax is less readable.
> > For example:
> >
> > type I2 interface {
> > (I1(int))
> > }
> >
> >
> > type S2 struct {
> > (S1(int))
> > }
> >
> >
> > We must use redundant brackets to keep the syntax right. I don't think
> this is readable and syntax consistent.
> >
> > The new syntax begin with < .It suggests the next name is generic. I
> think that's more readable.
>
> I agree that the syntax for embedding an instantiated type is not great.
>
> But I also think that embedding an instantiated type is a an unusual
> thing to do. It's not so bad if the syntax for an unusual operation
> doesn't look that great. It will rarely be seen.
>
> Is there some reason to think that people will often want to embed
> instantiated types?
>
It might not be as uncommon as you think. It'll happen any time that
someone wishes
to embed a container type and add some extra domain-specific methods.
I understand the necessity for the extra bracket in interface types, but I
don't really see that it's needed in struct types. Couldn't we use a
similar approach as for unnamed function parameter types
<https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#using-generic-types-as-unnamed-function-parameter-types>
by
changing gofmt to rewrite:
type T struct {
F(int)
}
to:
type T struct {
F int
}
and then later dropping the requirement for the extra brackets?
How many instances of the former are out there in the wild, I wonder.
cheers,
rog.
> .
> Ian
>
>
> > On Tuesday, June 23, 2020 at 1:53:56 AM UTC+8, Ian Lance Taylor wrote:
> >>
> >> On Mon, Jun 22, 2020 at 10:09 AM James L <jamesl...@gmail.com> wrote:
> >> >
> >> > Have you read other thread which have been answered many times?
> >>
> >> In fairness, this idea is different, because the type comes first.
> >> Since the '<' character will always be the start of an expression, I
> >> think it may be unambiguous. I think this has been suggested before
> >> also, though I'm not sure where.
> >>
> >> I don't personally like this syntax because it seems to put the cart
> >> before the horse. In a function call, I would expect to see the Print
> >> function with a type argument int. This flips the order so that we
> >> see int first, then we see that we are talking about the Print
> >> function. Even if it could work syntactically, it seems to me to be
> >> less readable.
> >>
> >> The goal in any syntax suggestion should be more than just "this might
> >> work." It should be "this is more readable and easier to understand."
> >> And personally I don't think this specific suggestion meets that
> >> goal.
> >>
> >> Thanks for the comment, though.
> >>
> >> Ian
> >>
> >>
> >> > On Tue, 23 Jun 2020 at 12:46 AM, <redst...@gmail.com> wrote:
> >> >>
> >> >> I read the new generic draft. And I know F<T>,F[T],F《T》 is
> discarded. I think put the type paremeter in front of the function name may
> be better. No ambiguous and more readable code.
> >> >>
> >> >> func Print(type T)(s []T) {
> >> >>
> >> >> }
> >> >>
> >> >> Print(int)([]int{1, 2, 3})
> >> >>
> >> >> func <type T>Print(s []T) {
> >> >>
> >> >> }
> >> >>
> >> >> <int>Print([]int{1, 2, 3})
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> 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 golan...@googlegroups.com.
> >> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c55ab443-4333-4def-9d9c-6657463a4a75o%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 golan...@googlegroups.com.
> >> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAHo5hB6-myagSyixYPfghVYBE3DUpQMYSj88%2BjB74hbJvzQApQ%40mail.gmail.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/9297b725-7fc2-4e23-bd55-763d9bf691f7o%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/CAOyqgcWraiNkaqi5cpTsW4%3D_SZDTOaX7RObd5b6hWYaMVN%3DEQA%40mail.gmail.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/CAJhgachuJ4V2E0M0-ZLhb%2BD0AFT9yfJpaAQUJ8UH0P5GhWvirg%40mail.gmail.com.
