Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

2020-09-09 Thread Steven Blenkinsop
On Tue, Sep 8, 2020 at 9:25 PM Ian Lance Taylor  wrote:

>
> I think that it's really crucial for type inference rules to be as simple
> and clear as possible.  There must never be any confusion as to what an
> inferred type might be.  In complicated cases, it's fine to explicitly list
> the type arguments.  In fact, it's more than fine: it's desirable.
>

This doesn't seem to be a complicated case. We just have a type parameter
that needs pointer methods in order to be passed to another function. I
wouldn't suggest making the inference rules more clever to compensate for
this case. As I mentioned, the compiler probably shouldn't be smart enough
to figure this out as written.

I think the difficulty is coming from conflicting requirements. For element
type inference, you want the freedom to be able to provide arbitrary named
composite types as arguments and get the element type based on structural
matching. But for derived type constraints, you really actually don't want
that extra degree of freedom in the identity of the composite type.
Instead, you want to constrain the specific derived type. Maybe it would be
better to allow derived types to be constrained directly:

https://go2goplay.golang.org/p/cLVkk4HGWre

type Constraint interface{
Method()
}

func Foo[T any, *T Constraint](_ T) {}

func Bar[T any, *T Constraint](t T) {
Foo(t)
}

It might seem weird to have a "parameter" which has to be a specific type
in relation to other parameters, but that's already what was happening with
constraint type inference. This is sort of similar to the original idea of
having pointer type constraints, except you need both T and *T as
parameters, with each being constrained separately.

This doesn't cover the use case of accepting named slice types and
inferring the element type, so constraint type inference would still be
needed. Of course, part of what makes constraint type inference appealing
is that it gets two birds with one stone, but it seems like the conflicting
requirements of the two use cases is undermining the value of both.

On Tue, Sep 8, 2020 at 9:25 PM Ian Lance Taylor  wrote:

> On Tue, Sep 8, 2020 at 5:47 PM Steven Blenkinsop 
> wrote:
>
> >
>
> > Reading over the pointer method example, I noticed that a derived type
> cannot be inferred in a nested call while leaving method constraints intact:
>
> >
>
> > type DerivedTypeConstraint[T any] interface {
>
> > type *T
>
> > Method()
>
> > }
>
> >
>
> > func Foo[T any, PT DerivedTypeConstraint[T]](_ T) {}
>
> >
>
> > func Bar[T any, PT DerivedTypeConstraint[T]](t T) {
>
> > Foo(t) // Error: *T has no methods
>
> > }
>
> >
>
> > type S struct{}
>
> >
>
> > func (S) Method() {}
>
> >
>
> > func main() {
>
> > Bar(S{}) // This is fine, PT gets inferred as *S, which implements Method
>
> > }
>
> >
>
> >
>
> > https://go2goplay.golang.org/p/9GMdhTbcMDs
>
> >
>
> > Obviously, you can work around this by passing PT explicitly rather than
> letting *T be inferred. It's just unfortunate that, even though *T must
> have any methods in the constraint on PT (any other type with the same
> underlying type would have no methods), the compiler isn't, and most likely
> shouldn't be, smart enough to figure that out. I'm not sure how to solve
> this, but I think it makes the design feel a little less polished.
>
>
>
> I think that it's really crucial for type inference rules to be as
>
> simple and clear as possible.  There must never be any confusion as to
>
> what an inferred type might be.  In complicated cases, it's fine to
>
> explicitly list the type arguments.  In fact, it's more than fine:
>
> it's desirable.
>
>
>
> 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/CANjmGJuAZv7AJ-mrBAmOENYj%3Dtn0NmmMtDPmY%2B_BeOuZEO1ACQ%40mail.gmail.com.


Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

2020-09-08 Thread Ian Lance Taylor
On Tue, Sep 8, 2020 at 5:47 PM Steven Blenkinsop  wrote:
>
> Reading over the pointer method example, I noticed that a derived type cannot 
> be inferred in a nested call while leaving method constraints intact:
>
> type DerivedTypeConstraint[T any] interface {
> type *T
> Method()
> }
>
> func Foo[T any, PT DerivedTypeConstraint[T]](_ T) {}
>
> func Bar[T any, PT DerivedTypeConstraint[T]](t T) {
> Foo(t) // Error: *T has no methods
> }
>
> type S struct{}
>
> func (S) Method() {}
>
> func main() {
> Bar(S{}) // This is fine, PT gets inferred as *S, which implements Method
> }
>
>
> https://go2goplay.golang.org/p/9GMdhTbcMDs
>
> Obviously, you can work around this by passing PT explicitly rather than 
> letting *T be inferred. It's just unfortunate that, even though *T must have 
> any methods in the constraint on PT (any other type with the same underlying 
> type would have no methods), the compiler isn't, and most likely shouldn't 
> be, smart enough to figure that out. I'm not sure how to solve this, but I 
> think it makes the design feel a little less polished.

I think that it's really crucial for type inference rules to be as
simple and clear as possible.  There must never be any confusion as to
what an inferred type might be.  In complicated cases, it's fine to
explicitly list the type arguments.  In fact, it's more than fine:
it's desirable.

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/CAOyqgcWrPLkq61GZBYQ%3Dt5zhnd%3DY%3DbtBhSEBT9XNmBnpfvVY3g%40mail.gmail.com.


Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

2020-09-08 Thread Steven Blenkinsop
Reading over the pointer method example, I noticed that a derived type
cannot be inferred in a nested call while leaving method constraints intact:

type DerivedTypeConstraint[T any] interface {
type *T
Method()
}

func Foo[T any, PT DerivedTypeConstraint[T]](_ T) {}

func Bar[T any, PT DerivedTypeConstraint[T]](t T) {
Foo(t) // Error: *T has no methods
}

type S struct{}

func (S) Method() {}

func main() {
Bar(S{}) // This is fine, PT gets inferred as *S, which implements Method
}


https://go2goplay.golang.org/p/9GMdhTbcMDs

Obviously, you can work around this by passing PT explicitly rather than
letting *T be inferred. It's just unfortunate that, even though *T *must* have
any methods in the constraint on PT (any other type with the same
underlying type would have no methods), the compiler isn't, and most likely
shouldn't be, smart enough to figure that out. I'm not sure how to solve
this, but I think it makes the design feel a little less polished.

On Fri, Aug 14, 2020 at 5:40 AM roger peppe  wrote:

>
>
> On Thu, 13 Aug 2020 at 23:30, Ian Lance Taylor  wrote:
>
>> On Thu, Aug 13, 2020 at 3:09 PM roger peppe  wrote:
>>
>>
>> >
>>
>>
>> > I do feel that the "all or nothing" nature of type parameter lists (if
>> you specify one type parameter, you must explicitly specify all of the
>> others too, even if they could otherwise be inferred) is likely to get in
>> the way here. I'd like to see a way to specify some type parameters and not
>> others, so that constraint type inference can work even when, for example,
>> there's a generic return type parameter that can't be inferred from the
>> arguments. We could potentially use an underscore for that.
>>
>>
>>
>>
>>
>> If I understand you correctly, we changed that when we added the
>>
>>
>> constraint type inference section.  See the updated
>>
>>
>>
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-inference
>>
>>
>> section.
>>
>
> Ah, that's useful and interesting, thanks. I suspect that being able to
> selectively omit type parameters could be useful though - for when there's
> no obvious ordering to the parameters and you want to infer some of the
> earlier types in the list while specifying some later ones. Maybe in
> practice it'll always be possible to use an explicit type conversion in a
> value parameter to do this though, especially if Steven
> Blenkinsop's ordering suggestions are followed (perhaps that could be a `go
> vet` checki).
>
>   cheers,
> rog.
>
>>
>>
>> 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/CAJhgacjPfoUp%2Bkhb4csuF%2Bz%3DTEWchZuSri94yTP4%2BtRvtnK5Ng%40mail.gmail.com
> 
> .
>
>
>

-- 
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/CANjmGJvgk%2BRgAgUwfgDutCGNiqZHzH0KCCh2aZ0Gp_UeG%2BHnjA%40mail.gmail.com.


Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

2020-08-14 Thread roger peppe
On Thu, 13 Aug 2020 at 23:30, Ian Lance Taylor  wrote:

> On Thu, Aug 13, 2020 at 3:09 PM roger peppe  wrote:
> >
> > I do feel that the "all or nothing" nature of type parameter lists (if
> you specify one type parameter, you must explicitly specify all of the
> others too, even if they could otherwise be inferred) is likely to get in
> the way here. I'd like to see a way to specify some type parameters and not
> others, so that constraint type inference can work even when, for example,
> there's a generic return type parameter that can't be inferred from the
> arguments. We could potentially use an underscore for that.
>
> If I understand you correctly, we changed that when we added the
> constraint type inference section.  See the updated
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-inference
> section.
>

Ah, that's useful and interesting, thanks. I suspect that being able to
selectively omit type parameters could be useful though - for when there's
no obvious ordering to the parameters and you want to infer some of the
earlier types in the list while specifying some later ones. Maybe in
practice it'll always be possible to use an explicit type conversion in a
value parameter to do this though, especially if Steven
Blenkinsop's ordering suggestions are followed (perhaps that could be a `go
vet` checki).

  cheers,
rog.

> 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/CAJhgacjPfoUp%2Bkhb4csuF%2Bz%3DTEWchZuSri94yTP4%2BtRvtnK5Ng%40mail.gmail.com.


Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

2020-08-13 Thread Steven Blenkinsop
On Thu, Aug 13, 2020 at 7:35 PM, jimmy frasche 
wrote:

> If I have
>   func F[type E interface{}, S constraints.Slice[E]]() S
> are the following equivalent:
>   F[int, []int]
>   F[int]
>   F[[]int]
> or are only 2 of the 3 permissible? Does that change if I swap the
> type parameters?


>From the section Ian linked:

"When only some type arguments are passed, they are the arguments for the
first type parameters in the list."


On Thu, Aug 13, 2020 at 7:35 PM, jimmy frasche 
wrote:

> If I have
>   func F[type E interface{}, S constraints.Slice[E]]() S
> are the following equivalent:
>   F[int, []int]
>   F[int]
>   F[[]int]
> or are only 2 of the 3 permissible? Does that change if I swap the
> type parameters?
>
> On Thu, Aug 13, 2020 at 4:31 PM Michael Jones 
> wrote:
> >
> > Yes, thank you. In intellectual shame I must say that I somehow
> understood that the generics needed to be "leaf" functions. Thank you for
> demonstrating my oversight. Happier now.
> >
> > Michael
> >
> > On Thu, Aug 13, 2020 at 3:47 PM Bakul Shah  wrote:
> >>
> >> On Aug 13, 2020, at 3:29 PM, Michael Jones 
> wrote:
> >> >
> >> > The all-or-none aspect would be sidestepped if it were allowed to
> define "partial generics":
> >> >
> >> > func A (T1, T2) (...){}
> >> >
> >> > func B(T)(...){ A(T,int)(...){...} }
> >> >
> >> > Allowing B to exist just means running the whole generic thing
> iteratively until no resolution is changed. If the fixed point still has
> generic types then the compilation is a failure, otherwise, a success.
> >>
> >> Do you mean something like this?
> https://go2goplay.golang.org/p/4I4y-dLC-Yp
> >>
> >> >
> >> > Seems useful to me. A generic balanced tree infrastructure could be
> "meta-instantiated" as a LLRB instance that still allows generic leaf types.
> >>
> >
> >
> > --
> > Michael T. Jones
> > michael.jo...@gmail.com
> >
> > --
> > 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/CALoEmQxTgQdhS2x4MU%3D_FcwBAJ09D68XnNYOQxy5YV7%2B6QOi0w%40mail.gmail.com
> .
>
> --
> 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/CANG3jXJ60zyaBsYmvOSJdgX3J%3DaB0_Taz2SnuM31Rg3N0bx8mw%40mail.gmail.com
> .
>

-- 
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/CANjmGJvdPHOC5Uw6DvSeZKXALNuQru_Uaod-cS05a7EAsG7XEw%40mail.gmail.com.


Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

2020-08-13 Thread jimmy frasche
If I have
  func F[type E interface{}, S constraints.Slice[E]]() S
are the following equivalent:
  F[int, []int]
  F[int]
  F[[]int]
or are only 2 of the 3 permissible? Does that change if I swap the
type parameters?

On Thu, Aug 13, 2020 at 4:31 PM Michael Jones  wrote:
>
> Yes, thank you. In intellectual shame I must say that I somehow understood 
> that the generics needed to be "leaf" functions. Thank you for demonstrating 
> my oversight. Happier now.
>
> Michael
>
> On Thu, Aug 13, 2020 at 3:47 PM Bakul Shah  wrote:
>>
>> On Aug 13, 2020, at 3:29 PM, Michael Jones  wrote:
>> >
>> > The all-or-none aspect would be sidestepped if it were allowed to define 
>> > "partial generics":
>> >
>> > func A (T1, T2) (...){}
>> >
>> > func B(T)(...){ A(T,int)(...){...} }
>> >
>> > Allowing B to exist just means running the whole generic thing iteratively 
>> > until no resolution is changed. If the fixed point still has generic types 
>> > then the compilation is a failure, otherwise, a success.
>>
>> Do you mean something like this? https://go2goplay.golang.org/p/4I4y-dLC-Yp
>>
>> >
>> > Seems useful to me. A generic balanced tree infrastructure could be 
>> > "meta-instantiated" as a LLRB instance that still allows generic leaf 
>> > types.
>>
>
>
> --
> Michael T. Jones
> michael.jo...@gmail.com
>
> --
> 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/CALoEmQxTgQdhS2x4MU%3D_FcwBAJ09D68XnNYOQxy5YV7%2B6QOi0w%40mail.gmail.com.

-- 
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/CANG3jXJ60zyaBsYmvOSJdgX3J%3DaB0_Taz2SnuM31Rg3N0bx8mw%40mail.gmail.com.


Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

2020-08-13 Thread Michael Jones
Yes, thank you. In intellectual shame I must say that I somehow understood
that the generics needed to be "leaf" functions. Thank you for
demonstrating my oversight. Happier now.

Michael

On Thu, Aug 13, 2020 at 3:47 PM Bakul Shah  wrote:

> On Aug 13, 2020, at 3:29 PM, Michael Jones 
> wrote:
> >
> > The all-or-none aspect would be sidestepped if it were allowed to define
> "partial generics":
> >
> > func A (T1, T2) (...){}
> >
> > func B(T)(...){ A(T,int)(...){...} }
> >
> > Allowing B to exist just means running the whole generic thing
> iteratively until no resolution is changed. If the fixed point still has
> generic types then the compilation is a failure, otherwise, a success.
>
> Do you mean something like this?
> https://go2goplay.golang.org/p/4I4y-dLC-Yp
>
> >
> > Seems useful to me. A generic balanced tree infrastructure could be
> "meta-instantiated" as a LLRB instance that still allows generic leaf types.
>
>

-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
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/CALoEmQxTgQdhS2x4MU%3D_FcwBAJ09D68XnNYOQxy5YV7%2B6QOi0w%40mail.gmail.com.


Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

2020-08-13 Thread Steven Blenkinsop
On Thu, Aug 13, 2020 at 6:30 PM Ian Lance Taylor  wrote:

>
> If I understand you correctly, we changed that when we added the
> constraint type inference section.  See the updated
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-inference
> section.


This change creates two types of type parameters: free type parameters and
*associated* type parameters. And it seems like type parameter lists should
always be specified in the following order:

   1. Free type parameters which *cannot* be inferred based on value
   arguments to the function, followed by
   2. Free type parameters which *can* be inferred based on value arguments
   to the function, followed by
   3. Associated type parameters.

Would this be something that would just be part of style guides, or could
it be enforced in some way (perhaps by a lint)?

Also, is there any suggested way for APIs to document where the "stops" are
between these three categories of type parameters? Currently, the only
possible delimiter is ',', which means type parameter lists currently have
to appear uniform unless you use inline comments.

On Thu, Aug 13, 2020 at 6:30 PM Ian Lance Taylor  wrote:

> On Thu, Aug 13, 2020 at 3:09 PM roger peppe  wrote:
> >
> > I do feel that the "all or nothing" nature of type parameter lists (if
> you specify one type parameter, you must explicitly specify all of the
> others too, even if they could otherwise be inferred) is likely to get in
> the way here. I'd like to see a way to specify some type parameters and not
> others, so that constraint type inference can work even when, for example,
> there's a generic return type parameter that can't be inferred from the
> arguments. We could potentially use an underscore for that.
>
> If I understand you correctly, we changed that when we added the
> constraint type inference section.  See the updated
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-inference
> section.
>
> 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/CAOyqgcVvLvuAVy%3DWVA2n4wCcpEKNfbxTN-d_K%3Dz8kz1oiK9Z3g%40mail.gmail.com
> .
>

-- 
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/CANjmGJujty1Xg03MttK4aFH_3GMs6BEQNWwZyfOwySKBv2_gnA%40mail.gmail.com.


Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

2020-08-13 Thread Bakul Shah
On Aug 13, 2020, at 3:29 PM, Michael Jones  wrote:
> 
> The all-or-none aspect would be sidestepped if it were allowed to define 
> "partial generics":
> 
> func A (T1, T2) (...){}
> 
> func B(T)(...){ A(T,int)(...){...} }
> 
> Allowing B to exist just means running the whole generic thing iteratively 
> until no resolution is changed. If the fixed point still has generic types 
> then the compilation is a failure, otherwise, a success.

Do you mean something like this? https://go2goplay.golang.org/p/4I4y-dLC-Yp

> 
> Seems useful to me. A generic balanced tree infrastructure could be 
> "meta-instantiated" as a LLRB instance that still allows generic leaf types.

-- 
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/797021AB-A5A4-490B-A07B-0BF4700FC429%40iitbombay.org.


Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

2020-08-13 Thread Ian Lance Taylor
On Thu, Aug 13, 2020 at 3:09 PM roger peppe  wrote:
>
> I do feel that the "all or nothing" nature of type parameter lists (if you 
> specify one type parameter, you must explicitly specify all of the others 
> too, even if they could otherwise be inferred) is likely to get in the way 
> here. I'd like to see a way to specify some type parameters and not others, 
> so that constraint type inference can work even when, for example, there's a 
> generic return type parameter that can't be inferred from the arguments. We 
> could potentially use an underscore for that.

If I understand you correctly, we changed that when we added the
constraint type inference section.  See the updated
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-inference
section.

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/CAOyqgcVvLvuAVy%3DWVA2n4wCcpEKNfbxTN-d_K%3Dz8kz1oiK9Z3g%40mail.gmail.com.


Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

2020-08-13 Thread Michael Jones
The all-or-none aspect would be sidestepped if it were allowed to define
"partial generics":

func A (T1, T2) (...){}

func B(T)(...){ A(T,int)(...){...} }

Allowing B to exist just means running the whole generic thing iteratively
until no resolution is changed. If the fixed point still has generic types
then the compilation is a failure, otherwise, a success.

Seems useful to me. A generic balanced tree infrastructure could be
"meta-instantiated" as a LLRB instance that still allows generic leaf types.


On Thu, Aug 13, 2020 at 3:09 PM roger peppe  wrote:

> That's interesting; thanks for the heads up.
>
> My initial reaction is that this perhaps feels a bit "clever", but perhaps
> this feeling will go away in time.
>
> 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 found this initial sentence describing the motivation behind the feature
> a bit abstract and hence hard to understand:
>
> Perhaps a tiny example might help at that point to orient the reader in
> the right direction?
>
>  Constraint type inference can only infer types if some type parameter has
>> a constraint that has a type list with exactly one type in it.
>
>
> When I first read the above, my first thought was: but it's not very
> useful then because when would you have a type list with only one type in?
> Of course, it becomes clear later that you'd define this kind of
> constraint precisely to use this feature, but perhaps the phrasing could be
> changed a little to make that more obvious?
>
> Overall, I like the fact that this feature uses the existing semantics of
> type lists and only extends the type-inference algorithm.
>
> I do feel that the "all or nothing" nature of type parameter lists (if you
> specify one type parameter, you must explicitly specify all of the others
> too, even if they could otherwise be inferred) is likely to get in the way
> here. I'd like to see a way to specify some type parameters and not others,
> so that constraint type inference can work even when, for example, there's
> a generic return type parameter that can't be inferred from the arguments.
> We could potentially use an underscore for that.
>
> So, for example:
>
>var f = DoubleDefined[MySlice, _]
>
> would be valid. f would be a function value of type func(MySlice) MySlice.
>
>   cheers,
> rog.
>
>
>
>
> On Thu, 13 Aug 2020 at 03:31, Ian Lance Taylor  wrote:
>
>> I just added a new section to the generics design draft describing
>> constraint type inference.  This is a generalization and
>> simplification of the earlier pointer method approach, which has now
>> been removed.  I would be happy to hear any comments.  Thanks.
>>
>>
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#constraint-type-inference
>>
>> 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/CAOyqgcX6AcGUt4e6JTMrxXkAtMRq%2Bo6zSVnjqchEroheYBP%2BBw%40mail.gmail.com
>> .
>>
> --
> 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/CAJhgaciL%3D0p3rwMOmXW3oxNFhKVWFa6bT6-SsBi-E5iaeFxYqQ%40mail.gmail.com
> 
> .
>


-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
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/CALoEmQxJM0%2Bi9ri9FMV0zQ2L6R9zvH5eHHbXEQYci5XW6dzwFg%40mail.gmail.com.


Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

2020-08-13 Thread roger peppe
That's interesting; thanks for the heads up.

My initial reaction is that this perhaps feels a bit "clever", but perhaps
this feeling will go away in time.

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 found this initial sentence describing the motivation behind the feature
a bit abstract and hence hard to understand:

Perhaps a tiny example might help at that point to orient the reader in the
right direction?

 Constraint type inference can only infer types if some type parameter has
> a constraint that has a type list with exactly one type in it.


When I first read the above, my first thought was: but it's not very useful
then because when would you have a type list with only one type in?
Of course, it becomes clear later that you'd define this kind of constraint
precisely to use this feature, but perhaps the phrasing could be changed a
little to make that more obvious?

Overall, I like the fact that this feature uses the existing semantics of
type lists and only extends the type-inference algorithm.

I do feel that the "all or nothing" nature of type parameter lists (if you
specify one type parameter, you must explicitly specify all of the others
too, even if they could otherwise be inferred) is likely to get in the way
here. I'd like to see a way to specify some type parameters and not others,
so that constraint type inference can work even when, for example, there's
a generic return type parameter that can't be inferred from the arguments.
We could potentially use an underscore for that.

So, for example:

   var f = DoubleDefined[MySlice, _]

would be valid. f would be a function value of type func(MySlice) MySlice.

  cheers,
rog.




On Thu, 13 Aug 2020 at 03:31, Ian Lance Taylor  wrote:

> I just added a new section to the generics design draft describing
> constraint type inference.  This is a generalization and
> simplification of the earlier pointer method approach, which has now
> been removed.  I would be happy to hear any comments.  Thanks.
>
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#constraint-type-inference
>
> 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/CAOyqgcX6AcGUt4e6JTMrxXkAtMRq%2Bo6zSVnjqchEroheYBP%2BBw%40mail.gmail.com
> .
>

-- 
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/CAJhgaciL%3D0p3rwMOmXW3oxNFhKVWFa6bT6-SsBi-E5iaeFxYqQ%40mail.gmail.com.


Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

2020-08-13 Thread Ian Lance Taylor
On Thu, Aug 13, 2020 at 9:22 AM jimmy frasche  wrote:
>
> Would the constraints package have Pointer[E], Slice[E], and so on?

Good question.  I don't know.  We can certainly add them if we see
people using them.


> What happens if you have
>   type SC(type E I) interface {
> type []E
>   }
> for some I? Generally it seems like something to avoid, but it would
> be needed for
>   type Map[type K comparable, V interface{}] interface {
> type map[K]V
>   }
> at least. Are those checked at the same time as methods?

Yes.  Constraints are used for constraint type inference, which gives
us the final set of type arguments.  Only once the type arguments are
fully known do we check that the constraints are satisfied.  So, yes,
this happens at the same time that we verify that the type arguments
have any required methods.


> Do chains of constraints like
>  func F[type T interface{}, PT Setter2[T], SPT SC[PT]](xs SPT) SPT
>  func G[type T interface{}, PT Setter2[T], S0 SC[T], S1[PT]](xs S0) S1
> work?

Yes.  The algorithm loops until there is nothing left to do.


Thanks for the feedback.

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/CAOyqgcU_aD8%3Dw12-FPeiUNKcCe1DSOWLiH203ay6ZPikvO5U0Q%40mail.gmail.com.


Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

2020-08-13 Thread jimmy frasche
I don't care for the (type T Equaler) example. It makes one thing look
like another.

The rest seems interesting. Obviating and generalizing the * syntax is
certainly promising and a nice justification for type lists.

Would the constraints package have Pointer[E], Slice[E], and so on?

What happens if you have
  type SC(type E I) interface {
type []E
  }
for some I? Generally it seems like something to avoid, but it would
be needed for
  type Map[type K comparable, V interface{}] interface {
type map[K]V
  }
at least. Are those checked at the same time as methods?

Do chains of constraints like
 func F[type T interface{}, PT Setter2[T], SPT SC[PT]](xs SPT) SPT
 func G[type T interface{}, PT Setter2[T], S0 SC[T], S1[PT]](xs S0) S1
work?

On Wed, Aug 12, 2020 at 7:31 PM Ian Lance Taylor  wrote:
>
> I just added a new section to the generics design draft describing
> constraint type inference.  This is a generalization and
> simplification of the earlier pointer method approach, which has now
> been removed.  I would be happy to hear any comments.  Thanks.
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#constraint-type-inference
>
> 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/CAOyqgcX6AcGUt4e6JTMrxXkAtMRq%2Bo6zSVnjqchEroheYBP%2BBw%40mail.gmail.com.

-- 
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/CANG3jXJme%2BL5FQ5sg600Wi7JORPbSAU%2B%3DG8BN590pnVG859W%2Bg%40mail.gmail.com.


[go-nuts] [ generics ] Added constraint type inference to the design draft

2020-08-12 Thread Ian Lance Taylor
I just added a new section to the generics design draft describing
constraint type inference.  This is a generalization and
simplification of the earlier pointer method approach, which has now
been removed.  I would be happy to hear any comments.  Thanks.

https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#constraint-type-inference

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/CAOyqgcX6AcGUt4e6JTMrxXkAtMRq%2Bo6zSVnjqchEroheYBP%2BBw%40mail.gmail.com.