It's hard to say exactly, at this point, because the spec-changes for
generics are not yet written.
I don't think the behavior you observe is bad, but we'll have to see how we
can put it into the spec.
Currently, function parameters are scoped to the function body. Uniqueness
is litigated via a separate rule. That explains why `func(x int) { var x
string }` complains about a re-declaration - both `x` are scoped to the
function body. With `func(x int) { { var x string } }`, the
variable-declaration is scoped to the inner block, while the parameter is
scoped to the body itself. This difference explains why your last example
compiles, but the previous doesn't.
The solution for type-parameters will probably be similar - they get scoped
to the function body (or type-literal), but get some extra rules for how
they are resolved inside the function signature itself. That could
relatively easily explain all the behavior you observe.
On Fri, Nov 12, 2021 at 2:55 PM T L <tapir....@gmail.com> wrote:
> This one compiles okay:
>
> func Bar2[T any](x T) T {
> {
> var T = x // T redeclared in this block
> return T
> }
> }
>
> So the parameter type is declared at the local top block?
>
>
> On Fri, Nov 12, 2021 at 9:43 PM T L <tapir....@gmail.com> wrote:
>
>> It is strange that my recent comments are deleted automatically if they
>> are posted from the web interface.
>> But now from the email interface.
>>
>> On Fri, Nov 12, 2021 at 9:40 PM T L <tapir....@gmail.com> wrote:
>>
>>> 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 6:03 PM Axel Wagner <
>>> axel.wagner...@googlemail.com> wrote:
>>>
>>>>
>>>>
>>>> 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/CAEkBMfFDnUdh3PwumHz%3DfB-90YQ37WWZKfGeAcrQNP_edSc01w%40mail.gmail.com.
