Interface arguments to generic functions

[burak serdar]

In the following program, it is valid to pass an interface to function P:

func P[T fmt.Stringer](x T) {
fmt.Println(x)
}

func main() {
var v fmt.Stringer
P(v)
}

However, there is no way for P to check if x is nil. This does not compile:

func P[T fmt.Stringer](x T) {
if x!=nil {
fmt.Println(x)
}
}

Is it possible to write a generic function that can test if its
argument with a constraint is nil?

[Ian Lance Taylor]

For an interface type the value "nil" is the zero value of the type,
so this is the general zero value issue mentioned at
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#the-zero-value

You can write

func P[T fmt.Stringer](x T) {

var zero T
if x!=zero {
fmt.Println(x)
}
}

Ian

[burak serdar]

But that breaks the generic function for non-interface types.

type Str string

func (s Str) String() string {return string(s)}

func main() {
P(Str(""))
}

Now the passed parameter is the zero value, but not nil.


> Ian

[Dan Kortschak]

Would that work for non-comparable types? Say the T has an underlying
[]int type, then the comparison is not against nil and you end up with
a panic.

[Ian Lance Taylor]

OK, but what are you really trying to check? Why do you want to check
that an interface is not the zero value while at the same time you
don't care whether a string is the zero value?

Ian

[Ian Lance Taylor]

Fair point. But I'm not sure what the goal is here. Perhaps if we
can define that we can figure out how to make it work.

Ian

[Dan Kortschak]

I can see value in it; we use the pattern sometimes of allocating a
slice for a nil destination and returning it or otherwise checking that
lengths match. That pattern would not be possible with this issue. The
use case would be single or double precision float slices. The same
thing happens with maps sometimes too.

[burak serdar]

As a generic-function writer, I do not know if the argument will be an
interface or a concrete type. I don't want to check if it is
zero-value, I want to check if it is nil, because I don't want it to
panic.

If I was to convert the following non-generic function to a generic one:

func f(x SomeIntf) {
if x!=nil {
x.Something()
}
...
}

the obvious way to do this is:

func f[T SomeIntf](x T) {
...
}

but I can no longer check if x is nil.

Treating nil-checks as a special case might work maybe?

>
> Ian

[Patrick Smith]

On Tue, Jan 19, 2021 at 7:06 PM burak serdar <bse...@computer.org> wrote:

However, there is no way for P to check if x is nil. This does not compile:

func P[T fmt.Stringer](x T) {
     if x!=nil {
        fmt.Println(x)
    }
}

Is this  doing what you want?

func P[T fmt.Stringer](x T) {

     if fmt.Stringer(x)!=nil {
        fmt.Println(x)
    }
}

https://go2goplay.golang.org/p/7S4RX5G3rT_3

[Brian Candler]

On Wednesday, 20 January 2021 at 03:06:43 UTC bbse...@gmail.com wrote:

Is it possible to write a generic function that can test if its
argument with a constraint is nil?

I think there is a deeper question in there.

In the Generics proposal, type constraints (other than type lists) take the form of interfaces.  For example, a generic type T may be constrained with interface C.

Question: if a function takes type T, does that permit *both* values of concrete types which implement C, *and* interface values which implement C?  Apparently it does:

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

That, to me, is surprising at first.  I write a generic function because I want it to be expanded for different concrete types; but then I am surprised to find it can also be used for dynamic runtime types.

In principle, I guess it shouldn't really matter, since whatever type is provided has the expected behaviour.  Except: as the OP observed, interface types have the ability to be "nil", which concrete types don't (bar pointers/slices).

The end result is there's a crucial but subtle difference between:

type Foo interface { ... }

func f(v Foo) ...

and 

type Foo interface { ... }

func f[T Foo](v T) ...

Given that the second case supports both concrete types *and* interface types, then it seems to me that comparing a value with nil is a semantically valid thing to do. If the function specialisation is a concrete type, then that comparison would always be false and the code path optimised out.

Alternatively, generics could exclude interface values.  But then you get the weird situation that a generic function declaration that *looks* like an interface type, explicitly disallows interface type values!

---- 8< ----

With my wild hat on: it makes me wonder what would happen if the generics proposal became nothing more than interfaces with linked constraints - so that you could say "this function takes a function of type T (interface C) and returns *the same type* T", or "this function takes a []T and returns a value of *the same type* T".

What I mean is, the difference between

func f(a, b fmt.Stringer) c fmt.Stringer { ... }

and

func f[T fmt.Stringer](a, b T) c T { ... }

would simply be that a, b and c had to be of the *same* concrete type - but were otherwise still interface values (and specialisation, if implemented, would just be a hidden optimisation).

The obvious problem is that if you actually pass interface values around, then many type-mismatch violations couldn't be detected until runtime.

However: I find the same problem occurs with the current generics implementation, *if* you pass interface variables.  Check this out:

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

Print2() expects that both arguments are of the same type - but in the final call, they are not!  There is neither compile-time nor run-time error.

ISTM that constrained interface types could also be checked at compile time, in the common case where the caller passes concrete types. Rewriting to use plain interfaces instead of generics:

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

I think that an interface type constraint system *could* statically check that both args of the first Print2() call were (or were not) the same type.

What you might end up with is linked type constraints being a natural extension of interfaces.  Generic specialisation would just be an optimisation on top of that (if the call site knows that a particular set of concrete types is being used).  Type lists could also become an extension of interfaces.

However, that's just off the top of my head.  Whilst I've been following generics intermittently, no doubt this has been considered (and discarded) before.

Regards, Brian.

[Axel Wagner]

On Wed, Jan 20, 2021 at 11:08 AM Brian Candler <b.ca...@pobox.com> wrote:

The end result is there's a crucial but subtle difference between:

type Foo interface { ... }

func f(v Foo) ...

and 

type Foo interface { ... }

func f[T Foo](v T) ...

Given that the second case supports both concrete types *and* interface types, then it seems to me that comparing a value with nil is a semantically valid thing to do.

FWIW, it's also possible to write a constraint that can *only* be satisfied by concrete types - namely one containing a type-list.

IMO it is confusing to allow comparing generic values to nil, in general. If we could, I would either assume I can compare any *non*-generic value to nil. I would assume we can always go from a generic function to an instantiated one by substituting all occurrences of the type-parameters. But IMO, nil is already confusing enough as it is.

I think the solutions Patrick and Ian provided for checking if an interface is nil, or a value is zero, are enough. Because, to be clear: Calling a method on an interface can panic *whether or not that interface is nil*. Fundamentally, the case where a caller passes you a nil-interface is not different from the case where a caller passes you an interface with a method that dereferences a nil-pointer or accesses a slice out of bounds - or an interface that just calls panic("foo") in one of its methods. It's a bug in the caller and panicing in such a case is the correct thing to do. You will never be able to statically catch all bugs or statically prevent all panics. I don't think this particular panic is special enough to give it extra attention - because, again, you *can* do the check, if you want to, it's just not super convenient.

If the function specialisation is a concrete type, then that comparison would always be false and the code path optimised out.

Alternatively, generics could exclude interface values.  But then you get the weird situation that a generic function declaration that *looks* like an interface type, explicitly disallows interface type values!

---- 8< ----

With my wild hat on: it makes me wonder what would happen if the generics proposal became nothing more than interfaces with linked constraints - so that you could say "this function takes a function of type T (interface C) and returns *the same type* T", or "this function takes a []T and returns a value of *the same type* T".

What I mean is, the difference between

func f(a, b fmt.Stringer) c fmt.Stringer { ... }

and

func f[T fmt.Stringer](a, b T) c T { ... }

would simply be that a, b and c had to be of the *same* concrete type - but were otherwise still interface values (and specialisation, if implemented, would just be a hidden optimisation).

The obvious problem is that if you actually pass interface values around, then many type-mismatch violations couldn't be detected until runtime.

However: I find the same problem occurs with the current generics implementation, *if* you pass interface variables.  Check this out:

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

Print2() expects that both arguments are of the same type - but in the final call, they are not!  There is neither compile-time nor run-time error.

ISTM that constrained interface types could also be checked at compile time, in the common case where the caller passes concrete types. Rewriting to use plain interfaces instead of generics:

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

I think that an interface type constraint system *could* statically check that both args of the first Print2() call were (or were not) the same type.

What you might end up with is linked type constraints being a natural extension of interfaces.  Generic specialisation would just be an optimisation on top of that (if the call site knows that a particular set of concrete types is being used).  Type lists could also become an extension of interfaces.

However, that's just off the top of my head.  Whilst I've been following generics intermittently, no doubt this has been considered (and discarded) before.

Regards, Brian.

--
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/34bdb40e-ad0b-47ce-8588-d014d0886470n%40googlegroups.com.

[Axel Wagner]

On Wed, Jan 20, 2021 at 11:08 AM Brian Candler <b.ca...@pobox.com> wrote:

With my wild hat on: it makes me wonder what would happen if the generics proposal became nothing more than interfaces with linked constraints - so that you could say "this function takes a function of type T (interface C) and returns *the same type* T", or "this function takes a []T and returns a value of *the same type* T".

What I mean is, the difference between

func f(a, b fmt.Stringer) c fmt.Stringer { ... }

and

func f[T fmt.Stringer](a, b T) c T { ... }

would simply be that a, b and c had to be of the *same* concrete type - but were otherwise still interface values (and specialisation, if implemented, would just be a hidden optimisation).

The only thing standing in the way of that is the requirement to enable operator usage. You can't use `+,<,*,…` on interface values, so if you require the design to support using them, the design *must* somehow encode a notion of specialization. I think if you'd remove that, the design is pretty much what you describe here (and, of course, it wouldn't require type-lists).

 

And FWIW, the design intentionally doesn't imply implementation choice - that is, in general, a compiler should be free to choose a pure boxing implementation already and AFAIK that's how the prototype works. That boxing implementation is more complicated though, than simply "put things into interfaces", because you need to provide access to operators.

The obvious problem is that if you actually pass interface values around, then many type-mismatch violations couldn't be detected until runtime.

However: I find the same problem occurs with the current generics implementation, *if* you pass interface variables.  Check this out:

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

Print2() expects that both arguments are of the same type - but in the final call, they are not!  There is neither compile-time nor run-time error.

ISTM that constrained interface types could also be checked at compile time, in the common case where the caller passes concrete types. Rewriting to use plain interfaces instead of generics:

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

I think that an interface type constraint system *could* statically check that both args of the first Print2() call were (or were not) the same type.

What you might end up with is linked type constraints being a natural extension of interfaces.  Generic specialisation would just be an optimisation on top of that (if the call site knows that a particular set of concrete types is being used).  Type lists could also become an extension of interfaces.

However, that's just off the top of my head.  Whilst I've been following generics intermittently, no doubt this has been considered (and discarded) before.

Regards, Brian.

--

[Brian Candler]

What do you make of this?

https://go2goplay.golang.org/p/gN-FK2kbYK5

Using interface values, it seems possible to bypass a declared constraint that two arguments have the same type.

I am wondering the following.

1. If the function signature says two types should be the same (via type parameters), but this can't be determined at compile time, then a runtime check should be inserted at the call point - and panic if fail.

2. Since a nil interface value has "no type", then nil interface values should be disallowed for arguments defined with type parameters. Again, if this can't be determined statically, then add a runtime check and panic.

Incidentally, point (2) also sidesteps the OP's original problem, since it guarantees the value can never be nil.

[Kevin Chadwick]

On 1/20/21 10:42 AM, 'Axel Wagner' via golang-nuts wrote:
> IMO it is confusing to allow comparing generic values to nil, in general. If we
> could, I would either assume I can compare any *non*-generic value to nil. I
> would assume we can always go from a generic function to an instantiated one by
> substituting all occurrences of the type-parameters. But IMO, nil is already
> confusing enough as it is.
>
> I think the solutions Patrick and Ian provided for checking if an interface is
> nil, or a value is zero, are enough. Because, to be clear: Calling a method on
> an interface can panic *whether or not that interface is nil*.

It looks to me like interfaces are causing a lot of problems in this proposal.
Although nil is largely a non issue in go compared to Dart where they are
pushing for migration to null soundness. I would personally like to see nil use
and related panics minimised further, if anything.

[Brian Candler]

On Wednesday, 20 January 2021 at 10:53:10 UTC axel.wa...@googlemail.com wrote:

On Wed, Jan 20, 2021 at 11:08 AM Brian Candler <b.ca...@pobox.com> wrote:

What I mean is, the difference between

func f(a, b fmt.Stringer) c fmt.Stringer { ... }

and

func f[T fmt.Stringer](a, b T) c T { ... }

would simply be that a, b and c had to be of the *same* concrete type - but were otherwise still interface values (and specialisation, if implemented, would just be a hidden optimisation).

The only thing standing in the way of that is the requirement to enable operator usage. You can't use `+,<,*,…` on interface values, so if you require the design to support using them

Yes.  Conceptually at least, interfaces defined as type lists could be used as interfaces:

type Foo interface { type int32, int64 }

func f(a, b Foo) {

    if (a < b) ...

}

 Without specialisation, there would be dynamic dispatch.  Internally it might work something like

    if (a.__lt__(b)) ...

At worst the __lt__ function for int32 uses reflection to check its right argument is int32.  However I believe go always requires that both arguments to "<" are the same type, so the compiler itself can check that.  In the above example this can be elided because it knows a and b are the same type; at worst it adds a run-time check.

Untyped constants are a problem though:

    if (a < 3) ...

 

And FWIW, the design intentionally doesn't imply implementation choice - that is, in general, a compiler should be free to choose a pure boxing implementation already and AFAIK that's how the prototype works. That boxing implementation is more complicated though, than simply "put things into interfaces", because you need to provide access to operators.

And parameterised types are still required, e.g.

type mycontainer[T any] []T

I am just wondering aloud if if it could be broken down to a set of orthogonal extensions:

1. Type parameters to functions (which can constrain interface arguments to have corresponding types)

2. Type parameters to types

3. Type lists in interfaces

That leaves generic specialisation as an internal optimisation, which in principle could apply to all interface arguments - although this would need to be controlled. e.g. you might not normally want to recompile large chunks of standard library which passes around io.Reader.

[Axel Wagner]

On Wed, Jan 20, 2021 at 12:04 PM Brian Candler <b.ca...@pobox.com> wrote:

What do you make of this?

https://go2goplay.golang.org/p/gN-FK2kbYK5

Using interface values, it seems possible to bypass a declared constraint that two arguments have the same type.

I understand if people are confused by it. I find it straight forward though - type-parameters express constraints on static types. From that perspective, the constraint isn't "bypassed". It's fulfilled - both arguments have the same static type.

Personally, I just don't see this cause a lot of practical problems. I can't imagine a lot of cases where you'd need two interface values to have the same dynamic value - except if you want to type-assert them, maybe to do some operation with them. Generics specifically exist to eliminate the need to do that.

In other words: If you want two values to have the same dynamic type, you probably want to do an operation to them, so you'll probably add a type-list to the constraint for the operation you want. At that point, the caller can no longer pass interface-values.

Can you come up with a realistic reason to have that constraint that doesn't end up needing reflect anyway (where you can implement any checks you want)?

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e4e446de-9be4-4e31-8df7-ed48998022een%40googlegroups.com.

[Brian Candler]

On Wednesday, 20 January 2021 at 11:53:23 UTC axel.wa...@googlemail.com wrote:

Can you come up with a realistic reason to have that constraint that doesn't end up needing reflect anyway (where you can implement any checks you want)?

Mainly it's programmer comfort.  If I write a container which holds a type T then:

1. I expect it to actually hold all values of the same type T, not a mixture of types A, B and C.

2. I expect it not to hold 'nil' values which have no concrete type at all

If I was happy with the mixture of different types and/or nil values, then I could have just used an interface in the first place, not generics.

I would get this comfort if interface types were *not* allowed to instantiate a generic type.  It would then be up to the caller to "concretize" interface values into real values, which in turn would also force the caller to check they were not nil.

However, it's all down to how the generic type is instantiated.  I guess I can just ignore this, and assume nobody "abuses" my generic code by instantiating it with an interface type.  As you said, this problem doesn't present for type lists, only for method interfaces.

[Axel Wagner]

On Wed, Jan 20, 2021 at 1:10 PM Brian Candler <b.ca...@pobox.com> wrote:

On Wednesday, 20 January 2021 at 11:53:23 UTC axel.wa...@googlemail.com wrote:

Can you come up with a realistic reason to have that constraint that doesn't end up needing reflect anyway (where you can implement any checks you want)?

Mainly it's programmer comfort.  If I write a container which holds a type T then:

1. I expect it to actually hold all values of the same type T, not a mixture of types A, B and C.

2. I expect it not to hold 'nil' values which have no concrete type at all

If I was happy with the mixture of different types and/or nil values, then I could have just used an interface in the first place, not generics.

I don't think this is true, in practice. In practice, there will be a common implementation, say `List[T any]` - and a `List[io.Reader]` is still better than a `List[interface{}]`. And note, that you *can* still get a `List[*bufio.Reader]` and in that case the compiler will diligently point out if you store the wrong thing.

And I think containers specifically will most often be declared either as a struct field, or as a variable - and in either case, you must spell out the type to instantiate it with. So, to run into this situation in the first case, you'd need to (for example) get your list out of a generic function, that you call with an interface-value and then store in a variable declaration (without type). And then you'd need to continue passing that around without ever mentioning it's type (or only in it's generic form). And then use it at a different part of your code which somehow needs a specific concrete type, but *doesn't mention it*.

So, overall, for containers specifically, I think a) it's incredibly rare to even run into the situation and b) either the compiler will catch the mistake, or your code doesn't actually care if the dynamic types of that interface are the same everywhere.

Also, to re-iterate: Interfaces have a type and that type is still being correctly asserted and nil is a valid and expected value of that type. So, I think another way to look at the problem is, that you seem to consider the dynamic type somehow the "actual" or "more real" type of an interface. And I think that would be understandable, because so far, we often *have* to use interfaces when we really mean a concrete type, to enable code-reuse and polymorphic functions. But, hopefully, in the-glorious-future™, this won't be needed anymore. And maybe we can get back to view interfaces as their own type :)

I would get this comfort if interface types were *not* allowed to instantiate a generic type.

I think that would be a very confusing and misguided restriction. For example, it is entirely reasonable to need a `List[ast.Node]`. For example, when implementing a function to walk an AST.

I *might* be convinced to disable type-inference if one of the inferred types is an interface type, though - that way, the situation also can't occur, because you need to explicitly spell out which type you want, but it is still possible to write any code you need.

However, it's all down to how the generic type is instantiated.  I guess I can just ignore this, and assume nobody "abuses" my generic code by instantiating it with an interface type. As you said, this problem doesn't present for type lists, only for method interfaces.

--

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/6a2eedda-47ea-4ab8-ab85-66239e3ec3bbn%40googlegroups.com.

[roger peppe]

On Wed, 20 Jan 2021 at 11:04, Brian Candler <b.ca...@pobox.com> wrote:

What do you make of this?

https://go2goplay.golang.org/p/gN-FK2kbYK5

Using interface values, it seems possible to bypass a declared constraint that two arguments have the same type.

This code is misleading. By passing the value to `reflect.TypeOf`, you're losing the actual type of the value by

converting it to interface{} first. Contrast your example with this, where we print the type of &a and &b instead

of a and b, and you'll see that actually the types are identical.

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

This all seems fine to me, tbh.

It does mean that you need to avoid invoking methods on freshly declared instances of generic types, but

that's true for non-interface types too (the type might be a pointer). You can also pass nil pointer values

as generic values, which can also panic when methods are invoked on them.

  cheers,

    rog.

[Ian Lance Taylor]

On Tue, Jan 19, 2021 at 10:02 PM burak serdar <bse...@computer.org> wrote:
>
> As a generic-function writer, I do not know if the argument will be an
> interface or a concrete type. I don't want to check if it is
> zero-value, I want to check if it is nil, because I don't want it to
> panic.

Other people in this thread have made useful comments. I want to add
that this request doesn't make sense to me. A generic type has
constraints that describe exactly what operations are permitted for
values of that generic type. The current proposal provides no way to
write a constraint for "can be compared to nil". If we could write
such a constraint, then if you used it, that type parameter could not
be instantiated by a numeric type or a string type. That doesn't seem
clearly useful.

It seems to me that what you are suggesting is something like "if a
type argument is an interface type, then permit comparing with nil."
I don't think that's a useful way to program in a language like Go.
Calling a method on a nil interface value will crash in a reliable and
dependable way, just as dereferencing a nil pointer will crash. There
is no more need to check for a nil interface value than there is a
need to check for a nil pointer value.

Finally, you can call this if you really must:

func IsNilInterface[T any](v T) bool {
typ := reflect.TypeOf(&v).Elem()
if typ.Kind() != reflect.Interface {
return false
}
return reflect.ValueOf(&v).Elem().IsZero()
}

Ian

[Ian Lance Taylor]

On Wed, Jan 20, 2021 at 2:08 AM Brian Candler <b.ca...@pobox.com> wrote:
>
> In the Generics proposal, type constraints (other than type lists) take the form of interfaces. For example, a generic type T may be constrained with interface C.
>
> Question: if a function takes type T, does that permit *both* values of concrete types which implement C, *and* interface values which implement C? Apparently it does:
> https://go2goplay.golang.org/p/sVaW1YoXKf1
>
> That, to me, is surprising at first. I write a generic function because I want it to be expanded for different concrete types; but then I am surprised to find it can also be used for dynamic runtime types.

I think that's a confusing way of describing what is happening. A
generic function can only be instantiated for different concrete
types. In many cases, an example of a concrete type that may be used
is an interface type. It's true that the values of an interface type
have a dynamic runtime type. But the interface type is still a
concrete type.

Ian

[Ian Lance Taylor]

On Wed, Jan 20, 2021 at 3:24 AM Brian Candler <b.ca...@pobox.com> wrote:
>
> Yes. Conceptually at least, interfaces defined as type lists could be used as interfaces:
>
> type Foo interface { type int32, int64 }
> func f(a, b Foo) {
> if (a < b) ...
> }
>
> Without specialisation, there would be dynamic dispatch. Internally it might work something like
>
> if (a.__lt__(b)) ...
>
> At worst the __lt__ function for int32 uses reflection to check its right argument is int32. However I believe go always requires that both arguments to "<" are the same type, so the compiler itself can check that. In the above example this can be elided because it knows a and b are the same type; at worst it adds a run-time check.

They are the same type, but that type is the interface type Foo. We
can define equality on interface types, by saying that different
dynamic types are not equal. But we can define a sensible ordering
type on interface types. The closest we could come would be to panic
if you use `__lt__` on interface types that have different dynamic
types. That could be done but seems unlikely to be useful.

Ian