Robert Griesemer comments

Results 88 comments of


                                            Robert Griesemer

proposal: make package initialization order within a series of import statements predictable and controllable

See also #31636. You can force the init order by ordering the imports accordingly and into "blocks" so that they don't get re-ordered ([example](https://go.dev/play/p/SAy_Zfpiyz4)). Note that this is not prescribed...

proposal: make package initialization order within a series of import statements predictable and controllable

VSCode's goimport doesn't rearrange imports in different groups if they are separated by a blank line: ```Go import ( _ "b" // blank line _ "a" ) ``` (at least...

proposal: make package initialization order within a series of import statements predictable and controllable

What matters here is also in which order the files are presented to the compiler by the `go` command. But I cannot but emphasize one more time: depending on these...

proposal: make package initialization order within a series of import statements predictable and controllable

@the-zucc The `go` command passes files to the compiler in lexical file name order.

cmd/compile: handle alias types in recursive types more consistently

See #50259 and #50276.

cmd/compile: handle alias types in recursive types more consistently

This error doesn't appear anymore due to some of the (partial) fixes done with the CLs above. There's still more to do to handle aliases correctly in all cases but...

cmd/compile: handle alias types in recursive types more consistently

Re-opened per previous comments and example: https://gotipplay.golang.org/p/mpONhtxQI4a

cmd/compile: handle alias types in recursive types more consistently

This appears to work now with GODEBUG=gotypesalias=1. Will add test and close.

Generics: cannot use common struct fields of a type set.

We don't currently support field accesses of this kind even though the proposal says that this should/could work. We may not support this for Go1.18 as it doesn't seem like...

Generics: cannot use common struct fields of a type set.

> Is there a more formal explanation for why this doesn't work beside "it wasn't implemented"? It'd be useful when explaining this issue to others. It seems to me that...