Type Parameters Proposal: constraint.Number should be replaced with constraints.Integer in the examples

[Manlio Perillo]

Hi.

I'm reading the Type Parameter Proposal to learn how to use type parameters and I noted that one of the example in the "Element constraint example" section uses the

constraints.Number constraint.  This constraint does not exist and probably should be replaced with constraints.Integer.

I hope that the typo is fixed, since currently the proposal document seems to be the only authoritative guide for type parameters.

Thanks

Manlio

[Axel Wagner]

There's also a new tutorial on the topic and the spec draft for Go 1.18 contains the changes for type parameters (though it seems not necessarily complete yet).

 

Thanks

Manlio

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7a12b4b6-ae90-4437-a557-8913f605ef0bn%40googlegroups.com.

[Manlio Perillo]

I read it, but it only shows simple examples.

The proposal shows a complex example like mutually referencing type parameters, several examples about non trivial cases and several examples for type inference.

[Ian Lance Taylor]

On Wed, Jan 19, 2022 at 1:50 AM Manlio Perillo <manlio....@gmail.com> wrote:
>
> I'm reading the Type Parameter Proposal to learn how to use type parameters and I noted that one of the example in the "Element constraint example" section uses the
> constraints.Number constraint. This constraint does not exist and probably should be replaced with constraints.Integer.

Thanks, fixed.

Ian

[Manlio Perillo]

I found other 2 issues:

1. In golang.org/design/43651-type-parameters#element-constraint-example,

    the type SC must use an approximation element ~[]E for V2 and V3 to compile.

2. In the same section, the document should add a DoubleDefined2 function, to

    show the new syntax introduced in #48424.

   func DoubleDefined2(S ~[]E, E constraints.Integer) S { ... }

Thanks

Manlio

[Manlio Perillo]

Found other issues.

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

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.

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?

P.S: should I report these issues on the Github Issue or on golang-dev?

Thanks

Manlio

[Ian Lance Taylor]

On Thu, Jan 20, 2022 at 12:12 AM Manlio Perillo
<manlio....@gmail.com> wrote:
>
> I found other 2 issues:
>
> 1. In golang.org/design/43651-type-parameters#element-constraint-example,
> the type SC must use an approximation element ~[]E for V2 and V3 to compile.
>
> 2. In the same section, the document should add a DoubleDefined2 function, to
> show the new syntax introduced in #48424.
>
> func DoubleDefined2(S ~[]E, E constraints.Integer) S { ... }

Thanks, fixed by dropping SC entirely. We don't need it any more.

Ian

[Ian Lance Taylor]

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

[Manlio Perillo]

There is a typo in the List[T].Range method, in  golang.org/design/43651-type-parameters#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#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

[Ian Lance Taylor]

On Fri, Jan 21, 2022 at 7:30 AM Manlio Perillo <manlio....@gmail.com> wrote:
>
> There is a typo in the List[T].Range method, in golang.org/design/43651-type-parameters#list-transform.
> The return type is *Iterator[T] but Iterator[T] is returned, instead.

Thanks again, fixed.

> Another issue is the implementation of AbsoluteDifference, in golang.org/design/43651-type-parameters#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, I'm going to leave this as is for now. 45639 is still open.

Ian

[Manlio Perillo]

On Friday, January 21, 2022 at 11:25:13 PM UTC+1 Ian Lance Taylor wrote:

> Another issue is the implementation of AbsoluteDifference, in golang.org/design/43651-type-parameters#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, I'm going to leave this as is for now. 45639 is still open.

However it is disallowed in go1.18.  In #50790 there is an alternate working solution.

 

Thanks

Manlio