On Friday, November 12, 2021 at 6:04:01 PM UTC+8 axel.wa...@googlemail.com
wrote:
> On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com <tapi...@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.
>
How much complicated? Is it similar to
func foo(int int) {}
>
>
>>
>>
>>>
>>> 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...@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/3d4fc243-f3dc-4071-b6ac-8c5462061e3en%40googlegroups.com.
