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
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
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
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
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
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
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:
>
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
>
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
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
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
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
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
> }
>
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
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.
15 matches
Mail list logo
