There is a typo in the List[T].Range method, in golang.org/design/43651-type-parameters <http://golang.org/design/43651-type-parameters#operations-based-on-type-sets> #list-transform. The return type is *Iterator[T] but Iterator[T] is returned, instead.
Another issue is the implementation of AbsoluteDifference, in golang.org/design/43651-type-parameters <http://golang.org/design/43651-type-parameters#operations-based-on-type-sets> #absolute-difference. The code is invalid due to #45639, but I suspect that the suggestion to use a struct type ComplexAbs[T OrderedNumeric] struct { X T } will not solve the problem. Moreover the code suggested in the issue: func (a ComplexAbs[T]) Abs() ComplexAbs[T] { d := math.Hypot(float64(real(a.X)), float64(imag(a.X))) return ComplexAbs[T](complex(d, 0)) } does not compile. Thanks Manlio On Thursday, January 20, 2022 at 8:46:19 PM UTC+1 Ian Lance Taylor wrote: > On Thu, Jan 20, 2022 at 2:28 AM Manlio Perillo <manlio....@gmail.com> > wrote: > > > > 1. In > golang.org/design/43651-type-parameters#constraints-apply-even-after-constraint-type-inference > , > > there is a typo in the F4 function where FromString2 should be > FromStrings2 > > Thanks, fixed. > > > 2. In > golang.org/design/43651-type-parameters#operations-based-on-type-sets, > > the link "defined later" in > > "For special purpose operators like range loops, we permit their use > > if the type parameter has a structural constraint, as <defined later>" > > points to > golang.org/design/43651-type-parameters#Constraint-type-inference. > > This feels confusing to me. What does type inference have to do with > structural constraints? > > > > I think that the definition of "structural type" and "structural > constraint" should be moved in a > > different section. > > Note that the term "structural constraint" is also used at the start of > the document, in > > golang.org/design/43651-type-parameters#background, but I'm not sure if > it has the > > meaning as the term used in the type inference section. > > This is historical. We introduced structural constraints for > constraint type inference, and then we started using them for some > operations. I'm honestly not sure if we are going to keep doing that > going forward in future language versions. > > I'm going to leave restructuring the documentation for later. > > > 3. I noted that in the design there are no examples of a generic > function that use the range > > statement over array, slice, string or map. What is the reason? > > Because we're not really sure how that is going to work. In > particular range is quite a different operation over []byte and > string, so it would be unusual for a generic function to do that. > > > > P.S: should I report these issues on the Github Issue or on golang-dev? > > Here is fine. Thanks. > > 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/3a5d8cc4-ea12-4dbc-bbbf-cd114f4f1196n%40googlegroups.com.
