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/CAEkBMfGd459fg74q%3DH6DDo0KH%2B-ZWQE-tyWb60r0_39dWbLcWw%40mail.gmail.com.
