On Wed, Jan 20, 2021 at 1:10 PM Brian Candler <b.cand...@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+unsubscr...@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
> <https://groups.google.com/d/msgid/golang-nuts/6a2eedda-47ea-4ab8-ab85-66239e3ec3bbn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAEkBMfFm-K%2BevnjatkwbGNWvE1ddO9OU4msBvb9Z0cvM_js-Uw%40mail.gmail.com.
