Also, just FTR, I agree with you that it would be nice to have
type-parameters on methods. I would very much like it if there was a way to
make it work.
However, your tone is very confrontational. The people who wrote that
design have spent a lot more time on thinking about this than you and you
should give them the benefit of the doubt that they wouldn't just leave
this out, if the issues were trivial to solve.
On Sat, Jun 20, 2020 at 9:51 PM Axel Wagner <axel.wagner...@googlemail.com>
wrote:
> You have not responded to the second concern, about
> interface-type-assertions requiring runtime instantiation of methods.
>
> On Sat, Jun 20, 2020 at 6:20 PM Carsten Orthbandt <
> carsten.orthba...@gmail.com> wrote:
>
>> Reflection certainly is a potential problem. But the only actual issue I
>> can see is the possibility of having multiple methods of the same name on a
>> type. Obviously, reflect.Type.MethodByName(string) would have to either
>> exclude or somehow distinguish the variants under a single name.
>>
>> I don't really consider that a real problem since reflect.Type is an
>> interface. The existing incarnations of that interface could simply ignore
>> type-param'ed methods and a new one be added for types that do have such
>> methods. With an added enumeration method for type-param'ed methods on a
>> type.
>> Just once idea, but the core is: Yes, reflection is an issue, but a
>> solvable one.
>>
>> Other than that, I don't see how
>>
>> func A(rcv Rcv,p1 P1, p2 P2)
>>
>> vs
>>
>> func (rcv Rcv) A(p1 P1, p2 P2)
>>
>> would cause trouble for the compiler. Heck, such parameterized methods
>> could be treated as syntactic sugar similar to how early C++ compilers did.
>> As far as I'm concerned, they wouldn't have to show up in the classic
>> reflection at all.
>>
>>
>>
>> On Saturday, June 20, 2020 at 5:38:34 PM UTC+2, Axel Wagner wrote:
>>>
>>> One way to see a problem pretty immediately is that `reflect` allows you
>>> to look up a type's method by name, but it doesn't allow you to do the same
>>> for functions. So you'd need a runtime-representation of generic functions
>>> of *some* sort. This is currently avoided by the restriction that you can't
>>> refer to an uninitialized generic function.
>>> Another (similar) problem is that you can do interface-type assertions.
>>> So, if you have `func (x *Foo) (type T) X(T)`, a type-assertion of the form
>>> `x.(interface{ X(T) }` would need to succeed for any `T`, even if the
>>> compiler didn't know it was needed. So you need a way to generate
>>> instantiations of generic functions at runtime as well. Those problems are
>>> probably solvable *somehow*, but it should be clear that it's a non-trivial
>>> problem on top of everything else.
>>>
>>> FWIW, I don't think adding this later will be much of a problem. What's
>>> considered idiomatic Go has changed in the past and will continue to
>>> change. For example, with the new APIs in the `errors` package, idiomatic
>>> error handling is changing. It's fine for things to change if we add
>>> type-parameter on methods as well.
>>>
>>> On Sat, Jun 20, 2020 at 3:32 PM Carsten Orthbandt <carsten....@gmail.com>
>>> wrote:
>>>
>>>> Hi!
>>>>
>>>> First, thanks to the Go team for the hard work and the list populace
>>>> for an extremely low-noise list. Very much appreciated.
>>>>
>>>> In the recent draft, struct methods with type parameters are explicitly
>>>> excluded with a note that they might be added later.
>>>> I think I roughly understand the added complexity of having basically
>>>> 2D type parameters (from the struct type itself and the mehtod).
>>>> However, and I'm really wondering why nobody brought this up, I think
>>>> this is a language element that would be quite akward to add later.
>>>>
>>>> Not because syntax would have to change in incompatible ways, but
>>>> because idiomatic Go will be forced to steer towards global functions for
>>>> this use case.
>>>>
>>>> Minimal example:
>>>> https://go2goplay.golang.org/p/CxK7EuhW_fF
>>>>
>>>> Please note that the struct type in this example does not even use type
>>>> parameters.
>>>>
>>>> With the method receiver really being just a 0th argument to a method,
>>>> I don't see why having type params on methods would be such a big
>>>> challenge.
>>>>
>>>>
>>>> Best Regards,
>>>> Carsten
>>>>
>>>>
>>>> --
>>>> 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 golan...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/golang-nuts/aa570653-56e4-492e-8640-4d4434cd2973o%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/golang-nuts/aa570653-56e4-492e-8640-4d4434cd2973o%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/aea3bde2-7465-4e5e-8677-9548b55e56e5o%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/aea3bde2-7465-4e5e-8677-9548b55e56e5o%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/CAEkBMfGhetXBqiq_qXxE-t-hQG0npjFQab80obcBjKehg87G5Q%40mail.gmail.com.
