Ian Lance Taylor schrieb am Dienstag, 18. August 2020 um 21:26:23 UTC+2:
> What would it mean to permit any type as a constraint?
>
Each type would match exactly the same types it would match in a plain old
function parameter list:
type MyStruct struct{}
func (s MyStruct) M() {}
== Type parameter list ==
[T int] // matches 1 type; useless, just for the sake of consistency
[T MyStruct] // matches MyStruct and
struct{}; useless as well
[T struct{}] // matches MyStruct and
struct{}; useless as well
[T interface{String() string}]
[T anyof{float32, float64}] // replacement for type lists in the current
draft
== Plain old function parameter list ==
(x int) // matches 1 type
(x MyStruct) // matches MyStruct and
struct{}
(x struct{}) // matches MyStruct and
struct{}
(x interface{String() string})
(x anyof{float32, float64}) // maybe in the future
> I actually looked into this, to see if we could say that any type
> could be used as a constraint, and say that a type parameter
> constraint would permit any type argument that is assignable to the
> constraint type. Unfortunately that leads to some odd behavior. If
> we use a named type as the constraint, it may have methods. But we
> can use a corresponding type literal as a type argument. That would
> add methods to a type literal with no explicit type conversion.
>
But isn't that already the case with normal function parameters?
package main
type S struct{}
func (s S) M() {}
func F(s S) {
s.M()
}
func main() {
// no explicit type conversion from struct{} to S
F(struct{}{})
}
https://play.golang.org/p/gDQfYUbe74w
> Similarly, if we use a type literal as a type, we can use a defined
> type as a type argument. But the generic function could assign the
> type parameter to some other defined type, and now we have a generic
> function that could not be compiled if we simply substituted the type
> argument for any instance of the type parameter.
>
Same here:
package main
type S struct{}
func (s S) M() {}
func F(s struct{}) {
var x S = s
_ = x
}
func main() {
// no explicit type conversion from S to struct{}
F(S{})
}
> And I don't see what we gain by following that path.
>
It would mostly be for the sake of consistency, and as a justification for
a hypothetical sum type like `anyof` (as a replacement for type lists in
interfaces) to be usable as a constraint.
--
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/86a3a82d-6f63-4efe-b72b-81bd1efabfa1n%40googlegroups.com.
