code review 142880043: spec: clarify variable initialization order (once more)

spec: specify variable initialization order explicitly

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 issue 8485.

[gri, 2014-09-11 04:44:28]

Hello r@golang.org, rsc@golang.org, iant@golang.org, ken@golang.org (cc:
golang-codereviews@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go

[gmk, 2014-09-11 11:43:09]

Initialization order should be independent of declaration order.  Please correct
me if I'm wrong.  Moving around top-level declarations should have no effect on
program behavior (with the exception of consts defined via iota).  Top-level
source order should be purely cosmetic.

To prevent programmers from relying on declaration ordering effects, compilers
should randomize the initialization order of independent variables.  This is
analogous to map iteration order.  (It might be a good idea to decide variable
initialization order at run time rather than compile time to ensure that a
diversity of orderings is exercised for a single compilation.)

It might seem like we can't weaken the spec, per the Go1 guarantee; it already
mentions source order.  However, according to issues 8052 and 7962, neither gc
nor gccgo currently respects source order, so no one can actually be depending
on it.

[iant, 2014-09-11 15:17:55]

On Thu, Sep 11, 2014 at 4:43 AM,  <gordon.klaus@gmail.com> wrote:
>
> Initialization order should be independent of declaration order.  Please
correct me if I'm wrong.  Moving around top-level declarations should have no
effect on program behavior (with the exception of consts defined via iota). 
Top-level source order should be purely cosmetic.
>
> To prevent programmers from relying on declaration ordering effects, compilers
should randomize the initialization order of independent variables.  This is
analogous to map iteration order.  (It might be a good idea to decide variable
initialization order at run time rather than compile time to ensure that a
diversity of orderings is exercised for a single compilation.)
>
> It might seem like we can't weaken the spec, per the Go1 guarantee; it already
mentions source order.  However, according to issues 8052 and 7962, neither gc
nor gccgo currently respects source order, so no one can actually be depending
on it.

All the compilers both respect source order, they just do in different
ways, because the rules are inconsistent.  Given

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

the rules say that b must be initialized before c.  However, since a
and c are independent, the rules also say that, because of source
order, c must be initialized before a and a must be initialized before
b.  Those rules can not all be satisfied, and gc and gccgo break the
rules in different ways.

I think we need to retain initialization in source order because the
dependency tracking is explicitly only within a single package.  If I
write

import "inits"

var a = inits.Call()
var b = inits.Call(0

I should be able to expect that a will get the first call and b will
get the second.

Ian

[gmk, 2014-09-11 16:07:28]

On Thu, Sep 11, 2014 at 5:17 PM, Ian Lance Taylor <iant@golang.org> wrote:

> All the compilers both respect source order, they just do in different
> ways, because the rules are inconsistent.
>

Oh, I see that I misread those issues.  So then it's probably not ok to
remove the source order guarantee in Go1.


> I think we need to retain initialization in source order because the
> dependency tracking is explicitly only within a single package.  If I
> write
>
> import "inits"
>
> var a = inits.Call()
> var b = inits.Call(0
>
> I should be able to expect that a will get the first call and b will
> get the second.
>

What does this example have to do with dependency tracking happening only
within a single package?  I think you could replace inits.Call() with
myFunc() to the same effect?

I understand that one could reasonably want two adjacent top-level
declarations to execute in source order.  My concern is with more distantly
separated declarations within the same file or in different files.  If code
is moved around or files are renamed then the initialization order might
change, and any code that was relying on that order would break.  Do you
see the parallel with map iteration order?  Maybe it seems unlikely to be a
problem, but then again, I never expected anyone to rely on map iteration
order either.

In my mind it just seems simpler to only consider source order within
function bodies, and to only consider dependency order for top-level
objects.

[gri, 2014-09-11 16:18:37]

I agree with the sentiment but in Go we have tried to make things
predictable rather than leave them unspecified if at all possible. Map
iterations and selects are notable exceptions: For map iterations, probably
the most sensible predictable iteration order would be "sorted order", but
in general the sort criteria is not clear and when we don't care about
order it would cost (a lot) extra to sort. For select statements, we want a
random execution of ready channel ops for fair scheduling.

But I see your point about global declarations being initialized in
dependency order or otherwise in unspecified order. Analogous to the
declaration order being irrelevant for the compiler. I think we would want
to extend this also to the order of init functions (where the order is
currently declaration order). I'd probably argue for this approach had I
thought about this enough before 1.0.

Not sure if we can make the change at this point - we would probably see
new errors in existing programs that relied on declaration order; as we
have seen errors in code using small maps which relied on map iteration
order. The difference being perhaps that program initialization happens
less often than map iteration, and so errors may not become obvious as
quickly.

- gri


On Thu, Sep 11, 2014 at 4:43 AM, <gordon.klaus@gmail.com> wrote:

> Initialization order should be independent of declaration order.  Please
> correct me if I'm wrong.  Moving around top-level declarations should have
> no effect on program behavior (with the exception of consts defined via
> iota).  Top-level source order should be purely cosmetic.
>
> To prevent programmers from relying on declaration ordering effects,
> compilers should randomize the initialization order of independent
> variables.  This is analogous to map iteration order.  (It might be a good
> idea to decide variable initialization order at run time rather than
> compile time to ensure that a diversity of orderings is exercised for a
> single compilation.)
>
> It might seem like we can't weaken the spec, per the Go1 guarantee; it
> already mentions source order.  However, according to issues 8052 and 7962,
> neither gc nor gccgo currently respects source order, so no one can
> actually be depending on it.

[rsc, 2014-09-12 04:08:51]

I think the approach here is good, and I think the choice of wording should be
made based on what is simplest for the implementation.

Here is the simple, efficient way to implement the gc ordering in a compiler:

for each variable v in source order:
    init(v)

init(v) =
    if v.done
        return
    if v.started
        report init loop (return error up stack, printing call trace as you go)
    v.started = true
    for each variable v1 in v's initializer
        init(v1)
    emit initialization of v
    v.done = true

It is a plain recursion, it walks each variable's initializer just once, there
is no data structure recording dependencies, and there is no search for the init
loop (it is exactly the stack of init calls, which can print out the deatils as
they return an error result up the call stack).

Is there a simple, efficient way to implement the gccgo ordering? All the
schemes I can think of are either inefficient (they scan the variables or the
initializer expressions multiple times) or complex (they require  auxiliary data
structures to record variable dependencies and compute ordering).

If not, I suggest to use the gc ordering.

Russ

[gri, 2014-09-12 15:38:01]

This algorithm is intriguing but also the reason why gc is still incorrect
in some cases: Interestingly, it neglects declaration order...

Consider:

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

Per the pseudo-code, the expected init order would be: c, b, a since
there's no provision for respecting declaration order of c and b. A quick
check confirms this: http://play.golang.org/p/jKg1CzPCwQ

I doubt that we want to codify that initialization order depends on whether
I write c + b vs b + c.

The CL proposes the following order:

b, c, a

(in this case this is the order for either of the two suggested variants in
the CL).

I believe adjusting the pseudo-code to first collect all the variables v1
in an initializer and handle them in sorted (declaration order) does not
actually fix the problem in all cases (but I don't have an example ready at
the moment).

- gri

On Thu, Sep 11, 2014 at 9:08 PM, <rsc@golang.org> wrote:

> I think the approach here is good, and I think the choice of wording
> should be made based on what is simplest for the implementation.
>
> Here is the simple, efficient way to implement the gc ordering in a
> compiler:
>
> for each variable v in source order:
>     init(v)
>
> init(v) =
>     if v.done
>         return
>     if v.started
>         report init loop (return error up stack, printing call trace as
> you go)
>     v.started = true
>     for each variable v1 in v's initializer
>         init(v1)
>     emit initialization of v
>     v.done = true
>
> It is a plain recursion, it walks each variable's initializer just once,
> there is no data structure recording dependencies, and there is no
> search for the init loop (it is exactly the stack of init calls, which
> can print out the deatils as they return an error result up the call
> stack).
>
> Is there a simple, efficient way to implement the gccgo ordering? All
> the schemes I can think of are either inefficient (they scan the
> variables or the initializer expressions multiple times) or complex
> (they require  auxiliary data structures to record variable dependencies
> and compute ordering).
>
> If not, I suggest to use the gc ordering.
>
> Russ
>
> https://codereview.appspot.com/142880043/
>

[rsc, 2014-09-12 16:10:26]

On Fri, Sep 12, 2014 at 11:38 AM, Robert Griesemer <gri@golang.org> wrote:

> This algorithm is intriguing but also the reason why gc is still incorrect
> in some cases: Interestingly, it neglects declaration order...
>
> Consider:
>
> var (
>    a = c + b
>    b = 1
>    c = 2
> )
>
> Per the pseudo-code, the expected init order would be: c, b, a since
> there's no provision for respecting declaration order of c and b. A quick
> check confirms this: http://play.golang.org/p/jKg1CzPCwQ
>
> I doubt that we want to codify that initialization order depends on
> whether I write c + b vs b + c.
>
> The CL proposes the following order:
>
> b, c, a
>
> (in this case this is the order for either of the two suggested variants
> in the CL).
>

Then I don't believe the language in the spec is actually precise. For the
gccgo variant of the text, given:

var (
    x = z
    y = 1
    z = 2
)

The text says "A variable x that is declared before a variable y in the
source will be initialized before y unless x depends on y.". In this
example, x does not depend on y, and yet moving x after z (as needed for
x=z) would mean x is NOT initialized before y.

Russ

[gri, 2014-09-12 18:07:18]

Hello r@golang.org, rsc@golang.org, iant@golang.org, ken@golang.org,
gordon.klaus@gmail.com, adonovan@google.com (cc:
golang-codereviews@googlegroups.com),

Please take another look.

[rsc, 2014-09-12 18:33:57]

I'm sorry for being pedantic but I'm still not sure this is precise. If you have

var (
    a = c
    b = c
    c = ...
)

Then both a and b move after c. I don't see any text saying that the relative
ordering is preserved by this movement.

[gri, 2014-09-12 20:34:19]

PTAL.

I have found it difficult to describe the intuitive informal rule (first
sentence in the section) formally. This new approach outlines an algorithm.

- gri


On Fri, Sep 12, 2014 at 11:33 AM, <rsc@golang.org> wrote:

> I'm sorry for being pedantic but I'm still not sure this is precise. If
> you have
>
> var (
>     a = c
>     b = c
>     c = ...
> )
>
> Then both a and b move after c. I don't see any text saying that the
> relative ordering is preserved by this movement.
>
>
> https://codereview.appspot.com/142880043/
>

[rsc, 2014-09-12 20:54:05]

https://codereview.appspot.com/142880043/diff/170001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142880043/diff/170001/doc/go_spec.html#newcode...
doc/go_spec.html:6086: a compiler may process multiple files belonging to the
same package in
This is a bit odd. No compiler I know does this. The build systems that invoke
the compiler do the sorting.

[gri, 2014-09-12 20:59:10]

PTAL

https://codereview.appspot.com/142880043/diff/170001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142880043/diff/170001/doc/go_spec.html#newcode...
doc/go_spec.html:6086: a compiler may process multiple files belonging to the
same package in
On 2014/09/12 20:54:05, rsc wrote:
> This is a bit odd. No compiler I know does this. The build systems that invoke
> the compiler do the sorting.

Acknowledged.

better?

(I do think we need to mention something somewhere. I do find it odd to insist
on a predictable and reproducible order otherwise).

[rsc, 2014-09-12 21:18:18]

https://codereview.appspot.com/142880043/diff/190001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142880043/diff/190001/doc/go_spec.html#newcode...
doc/go_spec.html:6085: Implementation restriction: To ensure reproducible
initialization behavior,
Yes, better. It's still a bit odd to me to call this one a restriction. I might
even say 'build systems are encouraged to present'.

[rsc, 2014-09-12 21:28:09]

https://codereview.appspot.com/142880043/diff/190001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142880043/diff/190001/doc/go_spec.html#newcode...
doc/go_spec.html:5927: More precisely, starting with the set <code>V</code> of
all package-level
I'm REALLY sorry, but this doesn't seem like what either gccgo or gc does.
Consider:

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

I think both gccgo and gc agree that the order here is b, a, c, but it seems to
me that this algorithm would use S={b,c} in the first pass and S={a} in the
second pass, leading to b,c,a.

How about this?

More precisely, define that a top-level variable is 'ready for initialization'
is not yet initialized and either it has no initialization expression or its
initialization expression has no dependencies on uninitialized variables.

Initialization proceeds as if by repeatedly initializing the top-level variable
that is earliest in declaration order and ready for initialization, until there
are no top-level variables ready for initialization.
When the process ends, if any variables are still uninitialized, those variables
form one or more initialization loops, and the program is not valid.

[gri, 2014-09-12 21:50:44]

https://codereview.appspot.com/142880043/diff/190001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142880043/diff/190001/doc/go_spec.html#newcode...
doc/go_spec.html:5927: More precisely, starting with the set <code>V</code> of
all package-level
On 2014/09/12 21:28:08, rsc wrote:
> I'm REALLY sorry, but this doesn't seem like what either gccgo or gc does.
> Consider:
> 
> var (
>     a = b
>     b = 1
>     c = 2
> )
> 
> I think both gccgo and gc agree that the order here is b, a, c, but it seems
to
> me that this algorithm would use S={b,c} in the first pass and S={a} in the
> second pass, leading to b,c,a.
> 
> How about this?
> 
> More precisely, define that a top-level variable is 'ready for initialization'
> is not yet initialized and either it has no initialization expression or its
> initialization expression has no dependencies on uninitialized variables.
> 
> Initialization proceeds as if by repeatedly initializing the top-level
variable
> that is earliest in declaration order and ready for initialization, until
there
> are no top-level variables ready for initialization.
> When the process ends, if any variables are still uninitialized, those
variables
> form one or more initialization loops, and the program is not valid.

Ah, yes. The loop handles each variable individually, rather than the set S at
once. Actually THAT is what both gccgo and go/types do. I've re-read my text too
often now and confused myself with the set S trying to be non-algorithmic.

Will update. Thanks.

[gri, 2014-09-12 22:09:40]

PTAL


On Fri, Sep 12, 2014 at 2:50 PM, <gri@golang.org> wrote:

>
> https://codereview.appspot.com/142880043/diff/190001/doc/go_spec.html
> File doc/go_spec.html (right):
>
> https://codereview.appspot.com/142880043/diff/190001/doc/
> go_spec.html#newcode5927
> doc/go_spec.html:5927: More precisely, starting with the set
> <code>V</code> of all package-level
> On 2014/09/12 21:28:08, rsc wrote:
>
>> I'm REALLY sorry, but this doesn't seem like what either gccgo or gc
>>
> does.
>
>> Consider:
>>
>
>  var (
>>      a = b
>>      b = 1
>>      c = 2
>> )
>>
>
>  I think both gccgo and gc agree that the order here is b, a, c, but it
>>
> seems to
>
>> me that this algorithm would use S={b,c} in the first pass and S={a}
>>
> in the
>
>> second pass, leading to b,c,a.
>>
>
>  How about this?
>>
>
>  More precisely, define that a top-level variable is 'ready for
>>
> initialization'
>
>> is not yet initialized and either it has no initialization expression
>>
> or its
>
>> initialization expression has no dependencies on uninitialized
>>
> variables.
>
>  Initialization proceeds as if by repeatedly initializing the top-level
>>
> variable
>
>> that is earliest in declaration order and ready for initialization,
>>
> until there
>
>> are no top-level variables ready for initialization.
>> When the process ends, if any variables are still uninitialized, those
>>
> variables
>
>> form one or more initialization loops, and the program is not valid.
>>
>
> Ah, yes. The loop handles each variable individually, rather than the
> set S at once. Actually THAT is what both gccgo and go/types
> <https://goto.google.com/types> do. I've
> re-read my text too often now and confused myself with the set S trying
> to be non-algorithmic.
>
> Will update. Thanks.
>
> https://codereview.appspot.com/142880043/
>

[iant, 2014-09-26 23:58:10]

LGTM

https://codereview.appspot.com/142880043/diff/310001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142880043/diff/310001/doc/go_spec.html#newcode...
doc/go_spec.html:5947: by the order in which the files are presented to the
compiler: Variables
s/Variables/variables/

[r, 2014-09-27 00:34:36]

LGTM but i may be missing something

https://codereview.appspot.com/142880043/diff/310001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142880043/diff/310001/doc/go_spec.html#newcode...
doc/go_spec.html:5925: <i>declaration order</i> but no sooner than any of the
variables
s/no sooner than/after/

https://codereview.appspot.com/142880043/diff/310001/doc/go_spec.html#newcode...
doc/go_spec.html:5947: by the order in which the files are presented to the
compiler: Variables
On 2014/09/26 23:58:09, iant wrote:
> s/Variables/variables/

stet: Upper case is correct when the fragment after the colon is a complete
sentence.

[gri, 2014-09-29 18:04:24]

https://codereview.appspot.com/142880043/diff/310001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142880043/diff/310001/doc/go_spec.html#newcode...
doc/go_spec.html:5925: <i>declaration order</i> but no sooner than any of the
variables
On 2014/09/27 00:34:36, r wrote:
> s/no sooner than/after/

Done.

https://codereview.appspot.com/142880043/diff/310001/doc/go_spec.html#newcode...
doc/go_spec.html:5947: by the order in which the files are presented to the
compiler: Variables
On 2014/09/27 00:34:36, r wrote:
> On 2014/09/26 23:58:09, iant wrote:
> > s/Variables/variables/
> 
> stet: Upper case is correct when the fragment after the colon is a complete
> sentence.

Acknowledged.

https://codereview.appspot.com/142880043/diff/310001/doc/go_spec.html#newcode...
doc/go_spec.html:5947: by the order in which the files are presented to the
compiler: Variables
On 2014/09/26 23:58:09, iant wrote:
> s/Variables/variables/

left alone per r

[rsc, 2014-09-29 18:21:21]

LGTM

This looks fine to me. I do not intend to address this for Go 1.4 in the gc
compiler.

https://codereview.appspot.com/142880043/diff/320001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142880043/diff/320001/doc/go_spec.html#newcode...
doc/go_spec.html:6065: sorted alphabetically, to a compiler.
I am not sure about the word alphabetically here. The sort order used today is
by Unicode code point, where B.go comes before a.go. But I don't have a better
phrasing so it's probably fine.

[gri, 2014-09-29 19:42:34]

https://codereview.appspot.com/142880043/diff/320001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142880043/diff/320001/doc/go_spec.html#newcode...
doc/go_spec.html:6065: sorted alphabetically, to a compiler.
On 2014/09/29 18:21:20, rsc wrote:
> I am not sure about the word alphabetically here. The sort order used today is
> by Unicode code point, where B.go comes before a.go. But I don't have a better
> phrasing so it's probably fine.
> 

changed to "lexical file name order" per suggestion from r

[gri, 2014-09-29 19:44:53]

*** Submitted as https://code.google.com/p/go/source/detail?r=191f9dc7d039 ***

spec: specify variable initialization order explicitly

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 issue 8485.

LGTM=iant, r, rsc
R=r, rsc, iant, ken, gordon.klaus, adonovan
CC=golang-codereviews
https://codereview.appspot.com/142880043

[gobot, 2014-09-29 20:30:51]

This CL appears to have broken the netbsd-amd64-bsiegert builder.
See http://build.golang.org/log/60ca55b8d7fbca41b22237e4cfb35af211d1ff01

[Ralph Corderoy, 2014-09-30 08:17:01]

https://codereview.appspot.com/142880043/diff/360001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142880043/diff/360001/doc/go_spec.html#newcode...
doc/go_spec.html:6064: to present multiple files belonging to the same package
in lexical file name
Can a build system's view of lexical filename ordering change according to the
user's locale?  Different users then build in a different order?

$ echo *; LC_ALL=C sh -c 'echo *'
a.go A.go á.go Á.go
A.go a.go Á.go á.go

[r, 2014-09-30 14:23:52]

https://codereview.appspot.com/142880043/diff/360001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142880043/diff/360001/doc/go_spec.html#newcode...
doc/go_spec.html:6064: to present multiple files belonging to the same package
in lexical file name
On 2014/09/30 08:17:01, Ralph Corderoy wrote:
> Can a build system's view of lexical filename ordering change according to the
> user's locale?  Different users then build in a different order?
> 
> $ echo *; LC_ALL=C sh -c 'echo *'
> a.go A.go á.go Á.go
> A.go a.go Á.go á.go

Yes, but this is an encouragement, not a requirement.

[adonovan, 2014-09-30 14:35:05]

https://codereview.appspot.com/142880043/diff/360001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142880043/diff/360001/doc/go_spec.html#newcode...
doc/go_spec.html:6064: to present multiple files belonging to the same package
in lexical file name
On 2014/09/30 08:17:01, Ralph Corderoy wrote:
> Can a build system's view of lexical filename ordering change according to the
> user's locale?  Different users then build in a different order?
> 
> $ echo *; LC_ALL=C sh -c 'echo *'
> a.go A.go á.go Á.go
> A.go a.go Á.go á.go

That's a question for your build system, not the spec.

The 'go build' tool sorts strings as byte sequences, so locale is irrelevant. 
Google's internal build system requires files to be enumerated explicitly in
order, so file name spelling isn't even relevant.

It varies.

[rsc, 2014-09-30 15:34:33]

On Tue, Sep 30, 2014 at 10:35 AM, <adonovan@google.com> wrote:

> Can a build system's view of lexical filename ordering change
>>
> according to the
>
>> user's locale?  Different users then build in a different order?
>>
>
>  $ echo *; LC_ALL=C sh -c 'echo *'
>> a.go A.go á.go Á.go
>> A.go a.go Á.go á.go
>>
>
> That's a question for your build system, not the spec.
>

This is exactly why we wrote lexical file name order instead of
alphabetical. The go command uses Unicode code point ordering, not whatever
the shell happens to say.

Russ

[adonovan, 2014-09-30 16:12:02]

https://codereview.appspot.com/142880043/diff/360001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142880043/diff/360001/doc/go_spec.html#newcode...
doc/go_spec.html:6064: to present multiple files belonging to the same package
in lexical file name
On 2014/09/30 14:35:05, adonovan wrote:
> On 2014/09/30 08:17:01, Ralph Corderoy wrote:
> > Can a build system's view of lexical filename ordering change according to
the
> > user's locale?  Different users then build in a different order?
> > 
> > $ echo *; LC_ALL=C sh -c 'echo *'
> > a.go A.go á.go Á.go
> > A.go a.go Á.go á.go
> 
> That's a question for your build system, not the spec.
> 
> The 'go build' tool sorts strings as byte sequences, so locale is irrelevant. 
> Google's internal build system requires files to be enumerated explicitly in
> order, so file name spelling isn't even relevant.
> 
> It varies.

Ignore me.  Right answer, wrong question. :)

[Ralph Corderoy, 2014-10-01 11:43:34]

If it's an encouragement then it's presumably to authors of build-tools that
aren't the already working go command.  go command provides a model to follow; 
Unicode code point ordering.  (Any normalization with that?)  Others should be
encouraged to copy it.

I don't read "lexical file-name order" as precisely "Unicode code-point order";
the former lets the reader use byte order, the latter makes him think about the
bytes' encoding.  Why not give them the whole "do it like this" clue to avoid
variation amongst those that want to comply?  It remains an encouragement.

[rsc, 2014-10-01 13:51:42]

On Wed, Oct 1, 2014 at 7:43 AM, <ralph.corderoy@gmail.com> wrote:

> I don't read "lexical file-name order" as precisely "Unicode code-point
> order"; the former lets the reader use byte order, the latter makes him
> think about the bytes' encoding.  Why not give them the whole "do it
> like this" clue to avoid variation amongst those that want to comply?
> It remains an encouragement.
>

For one thing, byte order and Unicode code-point order are the same, so it
doesn't really matter.

Russ