10

Is there any way to force the static field initialization order in partial classes? Let's say in HelloWorld1.cs I have:

partial class HelloWorld
{
  static readonly string[] a = new[] { "Hello World" };
}

Elsewhere in HelloWorld2.cs I have:

partial class HelloWorld
{
  static readonly string b = a[0];
}

If a is initialized before b this is fine but if b is initialized before a then it throws an. The healthy way is probably to use a static constructor but I'm curious if there's a way to force or predict the initialization order when the fields classes are in different files of the same partial class.

Alton XL
  • 635
  • 6
  • 18
  • What is your use case? In the example you have given, b will return the expected value from a[] whenever it's used. So, I'm not clear on why you care... – Silas Reinagel Mar 16 '15 at 21:08
  • 1
    You have your answer right in the question. You should be using a static constructor. – Servy Mar 16 '15 at 21:09
  • 1
    @SilasReinagel, it won't always be the case. If b is initialized before a the class will throw an error on static initialization. Within the same file the ordering is textual but what about between different files of the same partial class? – Alton XL Mar 16 '15 at 21:09
  • @Servy, thanks. Do you suppose the static constructor the only answer (it's probably the correct answer)? It seems ordering can't be forced but is it predictable? – Alton XL Mar 16 '15 at 21:10
  • 3
    @AltonXL The code is going to be extraordinarly fragile, far less readable, and harder to maintain, even if there *is* a defined ordering. You're far better off assuming there is no well defined ordering, regardless of whether or not one exists. – Servy Mar 16 '15 at 21:12
  • 1
    Take a look at this http://stackoverflow.com/questions/7965830/is-the-textual-order-across-partial-classes-formally-defined – Bilal Bashir Mar 16 '15 at 21:16
  • @Servy, thanks for explaining the reasons one should avoid depending on the initialization order but I'd still like to know if the order of initialization is predictable. – Alton XL Mar 16 '15 at 21:22

2 Answers2

16

When the fields are present in the same file, the textual order defines the execution of their initialization:

10.5.5.1 Variable initializers - Static field initialization

The static field variable initializers of a class correspond to a sequence of assignments that are executed in the textual order in which they appear in the class declaration. If a static constructor (§10.12) exists in the class, execution of the static field initializers occurs immediately prior to executing that static constructor. Otherwise, the static field initializers are executed at an implementation-dependent time prior to the first use of a static field of that class.

However, in the case of fields declared in different files of partial classes, the order is undefined:

10.2.6 Partial types - Members

The ordering of members within a type is rarely significant to C# code, but may be significant when interfacing with other languages and environments. In these cases, the ordering of members within a type declared in multiple parts is undefined.

From the C# language specification.

Community
  • 1
  • 1
Otiel
  • 18,404
  • 16
  • 78
  • 126
1

From MSDN Documentation:

The static field variable initializers of a class correspond to a sequence of assignments that are executed in the textual order in which they appear in the class declaration. If a static constructor (Section 10.11) exists in the class, execution of the static field initializers occurs immediately prior to executing that static constructor. Otherwise, the static field initializers are executed at an implementation-dependent time prior to the first use of a static field of that class.

Silas Reinagel
  • 4,155
  • 1
  • 21
  • 28
  • 2
    The textual order is predictable when all fields of the same partial class are in the same file. I'm curious what about when in different files. Is it the text order of the .cs file name then? – Alton XL Mar 16 '15 at 21:12
  • @AltonXL The order in that case is implementation specific and is not defined in the spec. Even if you can figure out the order it is doing in this build of the .NET CLR a windows update could break your program by changing the order it does the processing. – Scott Chamberlain Mar 16 '15 at 21:17
  • @ScottChamberlain, thanks for explaining the reasons one should avoid depending on the initialization order but I'd still like to know if the order of initialization is predictable. – Alton XL Mar 16 '15 at 21:22
  • 1
    @AltonXL It is not predictable from looking at the declaration site alone. – Silas Reinagel Mar 16 '15 at 21:23