> 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 piątek, 24 września 2021 o 19:34:43 UTC+2 Ian Lance Taylor napisał(a): > 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 > -- 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/a4afcba3-06f0-4fa7-a89d-85429c98b531n%40googlegroups.com.
