On Friday, November 12, 2021 at 6:07:11 PM UTC+8 axel.wa...@googlemail.com 
wrote:

> And FWIW, just to illustrate the expected complexity: We also want these 
> two declarations to mean the same:
> func A[T A]()
> func B[T interface{ A }]()
> So the rules also need to accommodate that. It gets only more complicated 
> from there.
>


Are the followings also intended?

func Foo[T any](T T) T { // (the 2nd) T redeclared in this block
    return T // T (type) is not an expression
}

func Bar[T any](x T) T {
    var T = x // T redeclared in this block
    return T
}
 

>
> On Fri, Nov 12, 2021 at 11:03 AM Axel Wagner <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.
>>  
>>
>>>  
>>>
>>>>
>>>> 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/02e92a27-93a3-41ab-9955-52898d494540n%40googlegroups.com.

Reply via email to