Addendum in case I wasn't clear:
I consider the absence of type-parameterized methods a bigger problem than
potentially required extensions to the reflection interfaces. Parens,
brackets or smiles for syntax? Yeah, I do have favorites, but it's not a
big deal. Contracts or interfaces? I prefer interfaces, but its not a big
deal in application. Not being able to orthogonally structure an
applications type family? That is a big deal in my view, borderline
embarrassing.
On Saturday, June 20, 2020 at 6:20:33 PM UTC+2, Carsten Orthbandt 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/72981bab-b072-41db-9f84-b2778c9fd7cao%40googlegroups.com.
