On Tue, Aug 18, 2020 at 11:29 AM Frederik Zipp <frederik.z...@gmail.com> wrote:
>
> The more I think about it the less I understand why type list should reside
> inside interfaces. I can only think of two reasons:
>
> 1) Avoid a new keyword for type lists.
> 2) The idea that only interfaces should be able to act as constraints.
>
> Regarding 2): Why this artificial limitation? Why not allow all types as
> constraints? Even int. It's nonsensical, but it would be like "interface{
> type int }" in the current draft, which is nonsensical, too. The rule would
> be simple: Any type can act both as normal type and as constraint. With the
> possible exception of `anyof`s, until there is a solution to use them as
> regular types as well.
Thanks for the comment.
What would it mean to permit any type as a constraint?
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.
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.
I know my descriptions are rather sketchy, but the point is that we
need a really clear definition of when a type argument satisfies a
type constraint, and of what operations a type constraint permits in
the generic function. I think we have a fairly clear understanding of
this when we permit interface types, with optional type lists, as type
constraints. I don't think we know what it means when we allow other
kinds of types as type constraints, and I don't see an obvious path
forward. And I don't see what we gain by following that path.
Thanks again.
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/CAOyqgcUFQEo-HJvaxfrP%2B6_iSojRXZ-qzfuqYaoj6ewiUX%2BCtw%40mail.gmail.com.
