Why not use <T>F in generic？

[redsto...@gmail.com]

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})

[James L]

Have you read other thread which have been answered many times?

--
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/c55ab443-4333-4def-9d9c-6657463a4a75o%40googlegroups.com.

[Ian Lance Taylor]

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

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAHo5hB6-myagSyixYPfghVYBE3DUpQMYSj88%2BjB74hbJvzQApQ%40mail.gmail.com.

[drc...@google.com]

We could regard the function as a method on the type(s), maybe?

Not sure if this is a good idea or not, especially since we don't have multimethods (methods applied to multiple values) for ordinary values.

[移库海牙客]

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.

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.

[Ian Lance Taylor]

On Mon, Jun 22, 2020 at 6:19 PM 移库海牙客 <redsto...@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

> 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/9297b725-7fc2-4e23-bd55-763d9bf691f7o%40googlegroups.com.

[移库海牙客]

Embed interface is common practice.

There is no extra cost in <T>F.

It is more readable because we can identify generic whenever we see <>. We must use more time to discover a generic using F(T), it looks like a function.

And it solve problems like embed types. 

Most people just don't get use to it now.

On Tuesday, June 23, 2020 at 10:05:01 AM UTC+8, Ian Lance Taylor wrote:

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9297b725-7fc2-4e23-bd55-763d9bf691f7o%40googlegroups.com.

[roger peppe]

On Tue, 23 Jun 2020 at 03:04, Ian Lance Taylor <ia...@golang.org> wrote:

On Mon, Jun 22, 2020 at 6:19 PM 移库海牙客 <redsto...@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 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.

.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWraiNkaqi5cpTsW4%3D_SZDTOaX7RObd5b6hWYaMVN%3DEQA%40mail.gmail.com.

[Hein Meling]

I think David Chase’s idea is interesting.

[i3dmaster]

Actually, this isn't too bad. Given Go already flips types and names in syntax, having the generic specification in front of the entity it decorates doesn't seem too alien looking. The too-mang-() concern has already brought up to the draft, I think it likely require some careful thinking... production code could be way more complicated than trivial examples, I hope bringing generics wouldn't kill the elegant looking and simplicity of Go code in large...

[Michael Jones]

Many (nearly all?) computer languages cater to English readers who have experience with certain noun/verb and noun/modifier ordering. 

Globally, “bird blue” and “pizza pepperoni” may be more common in other natural languages than blue bird and pepperoni pizza. 

The proposed order, “the T type of...” is not so unusual, arguably more usual in natural language. 

Michael

--
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/cf511869-052e-4964-a9c6-89b136f82da4o%40googlegroups.com.

--

Michael T. Jones
michae...@gmail.com