shadowing of types by variables

[Gorka Guardiola]

These programs compile and work according to my reading of the spec, but I found them surprising.

https://go.dev/play/p/EUZ_28jge1N

https://go.dev/play/p/NMhR1Nq1COw

According to the spec it seems like it is legal to shadow a type with a variable, even a builtin type.

Is there any specific rationale for this? I guess that it makes scoping checks easier and faster, but still.

More "interesting" programs in the same vein:

https://go.dev/play/p/_KburW2YuCG
https://go.dev/play/p/JTkvW7jsvyX
https://go.dev/play/p/tDji-HNo1_W

--

- curiosity sKilled the cat

[Brian Candler]

The rationale, I understand, is that it helps with the Go compatibility promise: when new types / constants / functions are added to the language, they don't break existing code.

[wagner riffel]

On 1/13/23 07:20, Gorka Guardiola wrote:
> According to the spec it seems like it is legal to shadow a type with a
> variable, even a builtin type.
> Is there any specific rationale for this? I guess that it makes scoping
> checks easier and faster, but still.
>

I don't think there is any special rationale behind it, in Go builtin
types are predefined identifiers, not keywords as usual in other
languages, thus those follow rules of identifiers, not keywords.
Although it feels astonishing that you can shadow even predefined
constants like "true := false", in my experience this haven't shown to
be an issue.

-w

[Ian Lance Taylor]

There is a rationale: we can add new predeclared identifiers without
breaking existing working code.

For example, the Go 1.18 release added two new predeclared
identifiers: `any` and `comparable`. Because they were predeclared
identifiers, not keywords, existing code that used them as variable
names continued to work.

Ian

[Gorka Guardiola]

Yes, I understood the idea from Brian's explanation. Makes adding new predeclared names (types, literals...) a compatible change.

Thanks.