On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com <tapir....@gmail.com>
wrote:

>
>
> On Friday, November 12, 2021 at 5:33:19 PM UTC+8 axel.wa...@googlemail.com
> wrote:
>
>> I suspect this issue is hard/impossible to avoid, because it must be
>> possible to self- and mutually reference type-parameters, in a way that
>> it's not for normal parameters, to allow to write something like
>>
>> type Equaler[T any] interface {
>>     Equal(T) bool
>> }
>> func Eq[T Equaler[T]](a, b T) bool {
>>     return a.Equal(b)
>> }
>>
>
> I don't see the same problem here. "T" and "Equaler" are two different
> identifiers.
>

But T and T are not.

The point I was making is that type-parameters must inherently be scoped in
a way that makes them visible in the type-list itself, to make writing code
like this possible. This isn't necessary for regular parameters and it's
what makes type-parameter lists special.

I *also* said that it's probably possible to devise rules which would make
this possible, while allowing the example you wrote, just that those rules
would have to be complicated.


>
>
>>
>> or basically any use-case for constraint-type inference.
>>
>> Even if we *could* allow it consistently, the rules for doing that would
>> likely be pretty complex. Better to take the relatively minor hit of
>> disallowing this overloading (you can always use different names for the
>> type-parameters, if they conflict with the constraint you want to use) than
>> to take the hit of complex scoping rules with lots of exceptions.
>>
>> On Fri, Nov 12, 2021 at 9:48 AM tapi...@gmail.com <tapi...@gmail.com>
>> wrote:
>>
>>> I expect the following code compilers okay, but it doesn't.
>>> It looks All the three "I" in the Bar function declaration are
>>> viewed as the type parameter, whereas the second one is
>>> expected as the constraint I (at least by me).
>>>
>>> package main
>>>
>>> type I interface { M() }
>>>
>>> func Foo(i I) {
>>>   i.M()
>>> }
>>>
>>> func Bar[I I](i I) { // cannot use a type parameter as constraint
>>>   i.M()
>>> }
>>>
>>> func main() {}
>>>
>>> --
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%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/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%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/CAEkBMfGe0WAm6K6eBWr23WgqZUhLMqt8F%2BTmsayDf53Uj9s8Jg%40mail.gmail.com.

Reply via email to