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 piątek, 10 września 2021 o 20:12:54 UTC+2 Kamil Ziemian napisał(a): > 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 > > > pt., 10 wrz 2021 o 19:07 Ian Lance Taylor <ia...@golang.org> napisał(a): > >> 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 >> > -- 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/65d6f0a2-446a-49f5-9751-796ff5434820n%40googlegroups.com.
