Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spec: variable initialization order still unclear #8485

Closed
griesemer opened this issue Aug 6, 2014 · 3 comments
Closed

spec: variable initialization order still unclear #8485

griesemer opened this issue Aug 6, 2014 · 3 comments
Milestone

Comments

@griesemer
Copy link
Contributor

Unfortunately, variable initialization order is still underspecified in the spec.
Consider (example courtesy of adononvan):

var (
   c = b + 2
   a = 1
   b = 2
)

Per the spec, because c depends on b, b must be initialized before c, leading to the
relative order: b c.

Variable a is independent of b and c, and thus, per the spec
(http://tip.golang.org/ref/spec#Program_initialization_and_execution):

"If two variables are independent of each other, they are initialized in the order
they are declared in the source, possibly in multiple files, as presented to the
compiler."

There are 3 possible places for a:

1) a b c => a before b which is correct, but not after c, which is in contradiction
to the spec
2) b a c => a neither before b nor after c, also a contradiction
3) b c a => a after c which is correct, but not before b, also in contradiction to
the spec

The spec rules cannot be satisfied in this case.

(Note that in this specific example, order doesn't matter since it's not visible, but in
the modified example: http://play.golang.org/p/67gMFZk7Sv it does matter).

For the reference:

gc produces the order: b c a
go/types and gccgo: produce the order: a b c

There a many related (and now closed) issues which we may want to verify against
(excluding duplocates):

issue #4648 (closest issue related to spec)
issue #6703
issue #7137
issue #7962
issue #7964
issue #8052
@gopherbot
Copy link

Comment 3:

CL https://golang.org/cl/142880043 mentions this issue.

@griesemer
Copy link
Contributor Author

Comment 4:

Status changed to Started.

@griesemer
Copy link
Contributor Author

Comment 5:

This issue was closed by revision 259f0ff.

Status changed to Fixed.

@griesemer griesemer self-assigned this Sep 29, 2014
@rsc rsc added this to the Go1.4 milestone Apr 14, 2015
@rsc rsc removed the release-go1.4 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 25, 2018
The existing spec rules on package initialization were
contradictory: They specified that 1) dependent variables
are initialized in dependency order, and 2) independent
variables are initialized in declaration order. This 2nd
rule cannot be satisfied in general. For instance, for

var (
        c = b + 2
        a = 0
        b = 1
)

because of its dependency on b, c must be initialized after b,
leading to the partial order b, c. Because a is independent of
b but is declared before b, we end up with the order: a, b, c.
But a is also independent of c and is declared after c, so the
order b, c, a should also be valid in contradiction to a, b, c.

The new rules are given in form of an algorithm which outlines
initialization order explicitly.

gccgo and go/types already follow these rules.

Fixes golang#8485.

LGTM=iant, r, rsc
R=r, rsc, iant, ken, gordon.klaus, adonovan
CC=golang-codereviews
https://golang.org/cl/142880043
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 26, 2018
The existing spec rules on package initialization were
contradictory: They specified that 1) dependent variables
are initialized in dependency order, and 2) independent
variables are initialized in declaration order. This 2nd
rule cannot be satisfied in general. For instance, for

var (
        c = b + 2
        a = 0
        b = 1
)

because of its dependency on b, c must be initialized after b,
leading to the partial order b, c. Because a is independent of
b but is declared before b, we end up with the order: a, b, c.
But a is also independent of c and is declared after c, so the
order b, c, a should also be valid in contradiction to a, b, c.

The new rules are given in form of an algorithm which outlines
initialization order explicitly.

gccgo and go/types already follow these rules.

Fixes golang#8485.

LGTM=iant, r, rsc
R=r, rsc, iant, ken, gordon.klaus, adonovan
CC=golang-codereviews
https://golang.org/cl/142880043
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jul 9, 2018
The existing spec rules on package initialization were
contradictory: They specified that 1) dependent variables
are initialized in dependency order, and 2) independent
variables are initialized in declaration order. This 2nd
rule cannot be satisfied in general. For instance, for

var (
        c = b + 2
        a = 0
        b = 1
)

because of its dependency on b, c must be initialized after b,
leading to the partial order b, c. Because a is independent of
b but is declared before b, we end up with the order: a, b, c.
But a is also independent of c and is declared after c, so the
order b, c, a should also be valid in contradiction to a, b, c.

The new rules are given in form of an algorithm which outlines
initialization order explicitly.

gccgo and go/types already follow these rules.

Fixes golang#8485.

LGTM=iant, r, rsc
R=r, rsc, iant, ken, gordon.klaus, adonovan
CC=golang-codereviews
https://golang.org/cl/142880043
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jul 30, 2018
The existing spec rules on package initialization were
contradictory: They specified that 1) dependent variables
are initialized in dependency order, and 2) independent
variables are initialized in declaration order. This 2nd
rule cannot be satisfied in general. For instance, for

var (
        c = b + 2
        a = 0
        b = 1
)

because of its dependency on b, c must be initialized after b,
leading to the partial order b, c. Because a is independent of
b but is declared before b, we end up with the order: a, b, c.
But a is also independent of c and is declared after c, so the
order b, c, a should also be valid in contradiction to a, b, c.

The new rules are given in form of an algorithm which outlines
initialization order explicitly.

gccgo and go/types already follow these rules.

Fixes golang#8485.

LGTM=iant, r, rsc
R=r, rsc, iant, ken, gordon.klaus, adonovan
CC=golang-codereviews
https://golang.org/cl/142880043
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants