On Fri, Nov 12, 2021 at 10:49 PM Ian Lance Taylor <i...@golang.org> wrote:
> On Fri, Nov 12, 2021 at 9:23 AM 'Axel Wagner' via golang-nuts
> <golang-nuts@googlegroups.com> wrote:
> >
> > On Fri, Nov 12, 2021 at 6:20 PM tapi...@gmail.com <tapir....@gmail.com>
> wrote:
> >>
> >> How much complicated? Is it similar to
> >>
> >> func foo(int int) {}
> >
> >
> > No. As I said, the situation is different, as type-parameters must be
> able to be self- and mutually referential.
>
> The scope of regular parameters starts at the beginning of the
> function body (https://golang.org/ref/spec#Declarations_and_scope,
> rule 4 in the list of rules).
>
> The scope of a type parameter starts at the beginning of the type
> parameter list (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#mutually-referencing-type-parameters
> ).
>
Just to nitpick, for eventual consideration when writing the spec. This
would, AIUI, imply that one of the above examples should compile, namely:
func F[T any]() {
const T = 42
}
If there is a new, implicit block surrounding the func-declaration (similar
to how we do it for if/for/switch <https://golang.org/ref/spec#Blocks>)
which type-parameters are bound to, the function body should be a *new*
scope and re-declaring T inside that new scope should be valid, as it's
more deeply nested.
I don't think it *should* be valid, just that the most straight forward way
to put this into rules is somewhat subtle.
>
> Ian
>
--
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/CAEkBMfGJmvRL3h5Ftdjg%2Bv955-pyx67aJO84poko6xVvdmJsfw%40mail.gmail.com.
