On Tue, Feb 15, 2022 at 2:33 PM Kamil Ziemian <kziemian...@gmail.com> wrote: > > Thank you Brian Cadler for short summary. After reading "Strings, bytes, > runes and characters in Go" blog post (https://go.dev/blog/strings), I tried > to read "Text normalization in Go" blog post > (https://go.dev/blog/normalization) and my brain twisted into Mobius strip. I > hope one day I will understand what is going on with that.
In case it isn't clear, the blog post https://go.dev/blog/normalization is about using Go to do text normalization. Text normalization is not a part of the Go language. > 1) In the first paragraph of "Constraint type inference" > (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#constraint-type-inference) > there is a sentence "Constraint type inference is useful when a function > wants to have a type name for an element of some other type parameter, or > when a function wants to apply a constraint to a type that is based on some > other type parameter.". I'm not sure what "a function wants to have a type > name for an element of some other type parameter" means. Does it means that > we have some "generic type parameter" (type parameter that takes another type > parameter as `NodeConstraind[Edge]`) or something else? In a function like func Insert[S ~[]E, E any](s S, i int, v ...E) S { E is a type name for an element of the type parameter S. > 2) In section "Function argument type inference" > (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#function-argument-type-inference) > we read that function argument type inference happens in two passes and > "When constraint type inference is possible, as described below, it is > applied between the two passes.". > > But in the section "Constraint type inference" > (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#constraint-type-inference) > we read that "When constraint type inference is possible, type inference > proceeds as followed:". Below list of the stages from this section > a) Build the mapping using known type arguments. > b) Apply constraint type inference. > c) Apply function type inference using typed arguments. > d) Apply constraint type inference again. > e) Apply function type inference using the default types of any remaining > untyped arguments. > f) Apply constraint type inference again. Yes, we're still working on the exact details of how inference is applied. The spec is the canonical reference here. When this has settled I may go back and update the proposal document. > 3) Second code example in "Type inference" > (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#type-inference) > has very big indentation. It should be removed. Hmmm, I don't see this. The second example is meant to be code that appears inside a function body, and at least on my web browser it seems to be indented the same as other code in function bodies. > 4) In section "Function argument type inference" > (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#function-argument-type-inference) > first, second and fourth code examples have very big indentation. They > should be removed. Same. 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/CAOyqgcVg%3Dtt0fAs4d4s3gk5q-%3DqbbBcFOXjsxkr9iY2cJ%2BOQ1g%40mail.gmail.com.
