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?
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.
