I think that might work, yes. At least I don't see a major issue with it
right now.
On Tue, Jan 9, 2024 at 7:25 PM roger peppe <rogpe...@gmail.com> wrote:
>
>
> On Fri, 5 Jan 2024 at 05:58, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> 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:
>>
>
> To my mind, there's a reasonably obvious way through the issue you
> outlined above (although there may well be more):
> allow a static reference to a field/method if all the embedded types are
> known, and not otherwise.
>
> So in the above example, `x.Read` in `main` is fine; `y.Read` in `main` is
> ambiguous due to two methods at the same level as you say;
> `x.Read` in `G` is not allowed because we don't statically know the method
> set of `x`. Likewise, we couldn't assign `x` to an `io.Reader`,
> but we *could* convert to `any` and then do a dynamic type conversion to
> `io.Reader` if we wished (which would fail in the *strings.Reader case
> but succeed in the int case).
>
> ISTM those semantics would be reasonably intuitive, and good compiler
> error messages could make it quite clear *why* we aren't allowed to
> reference such methods statically.
>
> cheers,
> rog.
>
>
>>
--
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/CAEkBMfF9a20ds%2BHrVE5DnZBBkr_UiYZFwgyOjrncBK6iBBHOwA%40mail.gmail.com.
