Type Parameters Proposal, few unimportant questions

[Kamil Ziemian]

Hello,

I try to work my way through "Type Parameters Proposal" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md). With my speed, I maybe and reading this very well written document before type parameters will be implemented in Go. xD Jokes aside, when I read it I found few sentences that sounds odd to me. Maybe some good soul would explain to me, am I right, or this is my bad, not good English?

At the beginning of the section (?) "Using a constraint" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#using-a-constraint) there is sentence "As shown above, constraints appear in the type parameter list as the meta-type of a type parameter." But I think that is should read "shown below".

In the second paragraph (?) of the section "Operations based on type sets" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#operations-based-on-type-sets) we read "For special purpose operators like range loops, we permit their use of the type parameter has a structural constraint". Meaning of it is clear to me (at least it is), but it sound odd when I read it. Maybe is should be something like "the type parameter that has a structural constraint"?

At the end totally pedantic hair splitting. At the end of the "Type sets" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#type-sets) we have code snippet "interface{ E1; E2}". I feel that more consistent with the rest of the code would be with one more space: "interface{ E1; E2 }".

Best,
Kamil

[Ian Lance Taylor]

On Fri, Sep 10, 2021 at 5:28 AM Kamil Ziemian <kziem...@gmail.com> wrote:
>
> I try to work my way through "Type Parameters Proposal" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md). With my speed, I maybe and reading this very well written document before type parameters will be implemented in Go. xD Jokes aside, when I read it I found few sentences that sounds odd to me. Maybe some good soul would explain to me, am I right, or this is my bad, not good English?
>
> At the beginning of the section (?) "Using a constraint" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#using-a-constraint) there is sentence "As shown above, constraints appear in the type parameter list as the meta-type of a type parameter." But I think that is should read "shown below".

I think "shown above" is correct. The document has already shown
using the constraint "any".

> In the second paragraph (?) of the section "Operations based on type sets" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#operations-based-on-type-sets) we read "For special purpose operators like range loops, we permit their use of the type parameter has a structural constraint". Meaning of it is clear to me (at least it is), but it sound odd when I read it. Maybe is should be something like "the type parameter that has a structural constraint"?

Thanks, it should be "if" rather than "of". I'll fix it.

> At the end totally pedantic hair splitting. At the end of the "Type sets" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#type-sets) we have code snippet "interface{ E1; E2}". I feel that more consistent with the rest of the code would be with one more space: "interface{ E1; E2 }".

Thanks, I'll fix that too.

Ian

[Kamil Ziemian]

Thank you very much, now this sentence about type parameters with structural constraint is clear and I know that I basically get it right.

Best

Kamil

[Kamil Ziemian]

Hello,

I finish reading this proposal (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md). It is hard to judge how much I understand of it probably between 40% and 70%, so I apologize if I make some stupid comment below, because I just miss something. Understand this whole text without running code in compiler is just above my mediocre (at best) programming skills. Compilers errors are one of mine favorite teachers. Also section "Discarded ideas" and "Examples" are quite easy to understand but I didn't count it my estimation above.

I need to say that I like what I understand. This proposal have a Go feeling, which is quite hard to describe. One part of it is stress on minimalism and simplicity, even as stated there this make Go more complicated. Other part is clearness of writing of these proposal in this part which I understand.

On the beginning of "More on type sets" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#more-on-type-sets) we read "These are not additional rules or concepts, but are consequences of how type sets work.". And in the subsection of it "Composite types in constraints" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#composite-types-in-constraints) under second code is stated "For composite types (string, pointer, array, slice, struct, function, map, channel) we impose an additional restriction: an operation may only be used if the operator accepts identical input types (if any) and produces identical result types for all of the types in the type set.".

I probably don't understand part of text that stated this rule before, but since I can't find it out, I wrote it down here to be sure.

In "What happened to contracts?" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#what-happened-to-contracts) we have "Type sets appeared only in contracts, rather than on interface types.". My English is not good enough to decide should it be "on interface types" or "in interface types". I have the same problem with title "Why not put type parameters on packages?" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#why-not-put-type-parameters-on-packages). "On packages" or "in packages"?

Pure curiosity. Why in "Containers" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#containers) in body of definition (?) of method "func (m *Map[K, V]) InOrder() *Iterator[K, V]", we have
var f func(*node[K, V]) bool
f = func(n *node[K, V]) bool { ... }
instead of code:
f := func(n *node[K, V]) bool { ... }

In "Type inference for composite literals" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#type-inference-for-composite-literals) in comment in the code (so this have no impact on the proposed code working) we have "inferred as Pair(int){1, 2}". Maybe I still don't understand this proposal enough, because I think it should be "Pair[int]{1, 2}".

Finally, some hair splitting.

In first code in "Both elements and methods in constraints" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#both-elements-and-methods-in-constraints), we have
"~int32| ~int64"
more consistent with rest of the code would be
"~int32 | ~int64".

In section "List transform" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#list-transform) in method func (lst *List[T]) Push(v T) we have
lst.tail.next = &element[T]{val: v }
For my money, space before last bracket should be removed to be consistent with other examples.

Best regards
Kamil

[Brian Candler]

On Thursday, 23 September 2021 at 18:07:19 UTC+1 kziem...@gmail.com wrote:

Understand this whole text without running code in compiler is just above my mediocre (at best) programming skills. Compilers errors are one of mine favorite teachers.

You can try out examples online in the go2 playground:

https://go2goplay.golang.org/

 

"inferred as Pair(int){1, 2}". Maybe I still don't understand this proposal enough, because I think it should be "Pair[int]{1, 2}".

An older version of the generics proposal used round parentheses for the type parameters, so a generic function call could look like "myfunc(int, string)(a, b)" when you weren't inferring the types.  This was changed to square brackets later.  I guess this comment is something that was missed.

[Kamil Ziemian]

You can try out examples online in the go2 playground:

https://go2goplay.golang.org/

Thank you Brian Candler for the information, I didn't know about go2 playground before. There are so many things that I need to learn about Go.

I guess this comment is something that was missed.

I also think this is the reason. I hope someone will correct it.

Best

Kamil

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/haLIqHOue7g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/0429f448-df3a-4adb-8c38-a6233d9af7f2n%40googlegroups.com.

[Ian Lance Taylor]

On Thu, Sep 23, 2021 at 10:07 AM Kamil Ziemian <kziem...@gmail.com> wrote:
>
> On the beginning of "More on type sets" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#more-on-type-sets) we read "These are not additional rules or concepts, but are consequences of how type sets work.". And in the subsection of it "Composite types in constraints" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#composite-types-in-constraints) under second code is stated "For composite types (string, pointer, array, slice, struct, function, map, channel) we impose an additional restriction: an operation may only be used if the operator accepts identical input types (if any) and produces identical result types for all of the types in the type set.".
>
> I probably don't understand part of text that stated this rule before, but since I can't find it out, I wrote it down here to be sure.

Thanks, I'll delete the sentence "these are not additional rules or
concepts." It was true a while back but it clearly no longer is.

> In "What happened to contracts?" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#what-happened-to-contracts) we have "Type sets appeared only in contracts, rather than on interface types.". My English is not good enough to decide should it be "on interface types" or "in interface types". I have the same problem with title "Why not put type parameters on packages?" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#why-not-put-type-parameters-on-packages). "On packages" or "in packages"?

Will change "on interface types" to "in interface types". "On
packages" is correct. Everything in Go can be described as being "in"
a package. The idea being discussed in that section is to add type
parameters to packages themselves, something like "package List[T
any]".

> Pure curiosity. Why in "Containers" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#containers) in body of definition (?) of method "func (m *Map[K, V]) InOrder() *Iterator[K, V]", we have
> var f func(*node[K, V]) bool
> f = func(n *node[K, V]) bool { ... }
> instead of code:
> f := func(n *node[K, V]) bool { ... }

It's a detail of Go scoping. If we write "f := func(...)" then f goes
into scope after that statement. As a consequence, if we used :=, the
recursive call to f in the function literal would not refer to the f
declared with the := statement, but to the f that is in scope before
the := statement. SInce there is no such f, that code would not
compile (and if there were such an f, it would be the wrong one). See
the discussion at https://golang.org/issue/33167.

> In "Type inference for composite literals" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#type-inference-for-composite-literals) in comment in the code (so this have no impact on the proposed code working) we have "inferred as Pair(int){1, 2}". Maybe I still don't understand this proposal enough, because I think it should be "Pair[int]{1, 2}".

Thanks, will fix.

> Finally, some hair splitting.
>
> In first code in "Both elements and methods in constraints" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#both-elements-and-methods-in-constraints), we have
> "~int32| ~int64"
> more consistent with rest of the code would be
> "~int32 | ~int64".

Thanks, will fix.

> In section "List transform" (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#list-transform) in method func (lst *List[T]) Push(v T) we have
> lst.tail.next = &element[T]{val: v }
> For my money, space before last bracket should be removed to be consistent with other examples.

Thanks, will fix.

Thanks for the careful reading.

Ian

[Kamil Ziemian]

> It's a detail of Go scoping. If we write "f := func(...)" then f goes into scope after that statement. As a consequence,

> if we used :=, the recursive call to f in the function literal would not refer to the f declared with the := statement,

> but to the f that is in scope before the := statement. SInce there is no such f, that code would not

> compile (and if there were such an f, it would be the wrong one). See the discussion at https://golang.org/issue/33167.

In the future I will read this discussion about closures and scoping, before that I still plenty materials about Go to read, listen and watch.

> Thanks for the careful reading.

I'm glad if I can help. :)

Best

Kamil