I'll make one more note, in an attempt to show that this problem is not
easy to solve:
Rust has generic methods. But it does not allow to use them in a "trait
object" (it calls that "object safety"). Go's interfaces are, primarily,
equivalent to Rust trait objects.
The fact that Rust has not figured out how to do this either should be an
indication, that this problem is hard.
Personally, I think that's the only way we could really get generic
methods: By making any interface that contains them only usable as a
constraint, just like we currently do with union elements. But it should be
noted that we really want to *remove* that distinction between constraint-
and general interfaces (by using union elements as union types), not widen
the gulf.
On Sun, 3 Nov 2024 at 07:59, Axel Wagner <axel.wagner...@googlemail.com>
wrote:
> On Sun, 3 Nov 2024 at 04:52, Mark Mavzon <markush...@gmail.com> wrote:
>
>> 1. For an interface's generic methods disallow the use of "any"
>> constraint for type parameters.
>> type HasIdentity interface {
>> Identity[T int64 | float64](T) T // ok
>> // Identifoo[T any](T) T // not allowed
>> }
>>
>
> I'll note that this is extremely unlikely to be accepted. It's a pretty
> ugly and arbitrary restriction.
>
> I also don't think it really fixes the problems. Whenever someone uses
> `any` in the relevant examples, they might as well add
> `SomeOtherwiseUnrelatedMethod()` to all the relevant interfaces for much of
> the same result (for example, instead of type-asserting from any to
> io.Closer, you'd type-assert from io.Reader to io.ReadCloser). It does
> *somewhat* reduce the issue, because it at least means only types which
> have at least that one method are relevant. But the basic issue remains.
>
> 5. When the whole program code is analyzed by the compiler we should know
>> exactly which types satisfy which interfaces and which types satisfy which
>> *constraints*.
>>
>
> There are circumstances in which this is not the case. For example, when
> using -buildmode=shared or -buildmode=plugin.
>
>
>> So...
>> 5a. Every generic method in every interface should be turned into several
>> non-generic methods with their type parameters substituted for every
>> possible concrete types according to their constraints. For the HasIdentity
>> example above we'll have:
>> type HasIdentity interface {
>> Identity[int64](int64) int64
>> Identity[float64](float64) float64
>> }
>> 5b. For every type that has generic methods and that satisfies some
>> interface the corresponding constraints from the interfaces' generic method
>> type parameters should be used to generate all possible method variations
>> for this type. So for the Foo struct above we know that according to its
>> generic Identity method signature it should satisfy the interface
>> HasIdentity so we take the corresponding type parameter constraint from
>> HasIdentity's method (int64 | float64) and use it to generate the needed
>> methods:
>> type Foo struct{}
>> func (foo Foo) Identity[int64](v int64) int64 { return v }
>> func (foo Foo) Identity[float64](v float64) float64 { return v }
>>
>> So the usage can be:
>> var a any = Foo{}
>> // the HasIdentity method table has 2 entries
>> // which map to the corresponding 2 entries in the Foo method table
>> h := a.(HasIdentity)
>> i := h.Identity(123)
>> f := h.Identity(1.0)
>>
>> Hopefully I conveyed the main idea. Looking forward to a feedback.
>>
>> On Tuesday, October 29, 2024 at 10:22:36 AM UTC+3 Axel Wagner wrote:
>>
>>> From an off-list response:
>>>
>>> 1. It only works if the function is defined in the same package as its
>>>>> used, or you'd need to use dot-imports.
>>>>
>>>> The dot-import in this case seems redundant because we have a variable
>>>> with which we try to use a method syntax and this variable has a specific
>>>> type and this type was defined in a specific package and all of this is
>>>> known at compile time. So can't the compiler just perform a check along the
>>>> lines of "if we use the method call syntax on this variable and if the type
>>>> of this variable is not an interface and if there's no method with the
>>>> required signature then check if there's a regular function with the
>>>> required signature defined in the same package as the type of the
>>>> variable"?
>>>>
>>>
>>> What you are describing here are effectively methods. You are just
>>> saying that, in addition to a method being declared as "func (T) M()`, it
>>> can also be declared as `func M(T)`. But nothing changes about the
>>> fundamental association between the body and the type, that characterizes a
>>> method. So it comes with exactly the same downsides as regular methods,
>>> with the added downside that we now have two different kinds of methods,
>>> that behave subtly differently (in that only one kind participates in
>>> interface implementation). It also means that a package can not define the
>>> generic `Map` method people seem to want on more than one type. Which,
>>> again, is unlikely to be what people want.
>>>
>>> I really encourage you to read #49085
>>> <https://github.com/golang/go/issues/49085>, if you find the FAQ entry
>>> unsatisfactory. It contains a lot of additional discussion and in
>>> particular this suggestion and probably every variation of it you can think
>>> of has been discussed there already.
>>>
>> --
>> 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 visit
>> https://groups.google.com/d/msgid/golang-nuts/616b3f30-f463-4f95-ad84-b3fd6a39ed87n%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/616b3f30-f463-4f95-ad84-b3fd6a39ed87n%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 visit
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHN3vvfj6v5EkP8DG-aC98VSy8x8OTz-wrEWHf3i3mo8Q%40mail.gmail.com.
