Hi,
I think the reason this has not happened is that it makes code using such a
type invalid, depending on the type-argument - in ways not captured by the
constraint. For example:
type X[T any] struct {
T
*bufio.Reader
}
func main() {
var x X[int]
x.Read // definitely refers to X.Reader.Read
var y X[*strings.Reader]
y.Read // ambiguous
}
Note, in particular, that this might happen very deeply in the call stack,
as you can have a generic function instantiating a generic type with a type
parameter as well.
func main() {
F[*strings.Reader]()
}
func F[T any]() {
G[T]()
}
func G[T any]() {
var x X[T]
x.Read
}
For us to actually allow embedding that way, one of three things would need
to happen:
1. We would have to decide to be happy with type-checking of generic code
only to happen at the instantiation site. That is what C++ is doing. It
seems very unlikely to me, that Go would ever do that - in fact "we
shouldn't do that" was one of the design constraints put unto generics. It
is bad if a seemingly innocuous and backwards-compatible change in a
library can break your code. Imagine that F and G above live in separate
modules and G introduces the x.Read call in a debug release - because it
seems innocuous and they tested it with their code and it works - because
*they* never instantiate it with an io.Reader. Then, after their release,
*your* code breaks, because you do.
2. We would have to enrich the constraint language to allow you to express
that kind of constraint. i.e. X's constraint would mention, that it can
only be instantiated with types that don't have a Read (or ReadByte,
ReadLine, …) field or method. Again, this seems very unlikely to me, as it
would require a really rich constraint language for relatively little
benefit. In particular, it seems likely that such a language would be
NP-complete to type check and we're unlikely to be happy about that. In
fact, if I may shamelessly plug that, I recently gave a talk about another
instance of a far more useful extension to the constraint language that we
disallow for that very reason
<https://www.youtube.com/watch?v=0w4Px-yR8D8&list=PLN_36A3Rw5hFsJqqs7olOAxxU-WJGlXS0&index=3>
.
3. Someone comes up with a clever new compromise. To me, this actually is
one of the more likely cases where a clever compromise could happen
(compared to things like "allowing methods in unions", or "allowing to pass
around uninstantiated generic functions" or "adding generic methods"). But
I'm not aware of anyone having proposed or seriously working on anything
like that.
So, in my opinion: I wouldn't hold my breath. I think it's unlikely this
will happen and definitely not any time soon.
On Fri, Jan 5, 2024 at 1:07 AM 'Sylvain Rabot' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> type Nullable[T any] struct {
> T
> valid bool
> }
>
Just as an aside: I think this is actually a pretty interesting example.
Because in my opinion, you absolutely *don't* want embedding to work here.
Because it would mean that you could use an invalid `Nullable[T]` as if it
was a valid one. And ISTM the entire point of a `Nullable[T]` should be, to
prevent those kinds of bugs. In fact, `*T` seems *strictly preferable* over
a `Nullable[T]` as described here, because at least it might catch these
bugs at runtime.
But of course, there are other cases where embedding type parameters might
be useful.
>
> Regards.
>
> --
> 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/f2b8c317-9530-45ff-b9f2-e9fe209a062cn%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/f2b8c317-9530-45ff-b9f2-e9fe209a062cn%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/CAEkBMfEJGHsF7AzFFNUGB2nZFstR9dZg9r57aOnDQLnGKARJvA%40mail.gmail.com.
