On Thu, Sep 23, 2021 at 10:07 AM Kamil Ziemian <kziemian...@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 -- 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/CAOyqgcVUdrNLAJzRLZw3BGpudnY-UE23x-5Gg-PMBzQcHUS6%3DA%40mail.gmail.com.
