Can VB.NET be forced to initialize instance variables BEFORE invoking the base type constructor?

Question

After debugging a particularly tricky issue in VB.NET involving the order in which instance variables are initialized, I discovered that there is a breaking discrepancy between the behavior that I expected from C# and the actual behavior in VB.NET.

^{Nota bene: This question concerns a slight discrepancy in the behaviors of VB.NET and C#. If you're a language bigot that is unable to provide an answer other than "that's why you should use C#, noob", there is nothing for you to see here; kindly move along.}

Specifically, I expected the behavior outlined by the C# Language Specification (emphasis added):

When an instance constructor has no constructor initializer, or it has a constructor initializer of the form base(...), that constructor implicitly performs the initializations specified by the variable-initializers of the instance fields declared in its class. This corresponds to a sequence of assignments that are executed immediately upon entry to the constructor and before the implicit invocation of the direct base class constructor. The variable initializers are executed in the textual order in which they appear in the class declaration.

Contrast that with the portion of the VB.NET Language Specification concerning Instance Constructors, which says (emphasis added):

When a constructor's first statement is of the form MyBase.New(...), the constructor implicitly performs the initializations specified by the variable initializers of the instance variables declared in the type. This corresponds to a sequence of assignments that are executed immediately after invoking the direct base type constructor. Such ordering ensures that all base instance variables are initialized by their variable initializers before any statements that have access to the instance are executed.

The discrepancy here is immediately obvious. C# initializes class-level variables before calling the base constructor. VB.NET does exactly the reverse, apparently preferring to call the base constructor before setting the values of instance fields.

If you want to see some code, this related question provides a more concrete example of the divergent behavior. Unfortunately, it does not provide any hints as to how one might coerce VB.NET into following the model established by C#.

I'm less interested in why the designers of the two languages chose such divergent approaches than I am in possible workarounds for the problem. Ultimately, my question is as follows: Is there any way that I can write or structure my code in VB.NET to force instance variables to be initialized before the base type's constructor is called, as is the standard behavior in C#?

Answer 1

If you have virtual members that are going to be invoked during construction (against best advice, but we've already agreed on that), then you need to move your initialization into a separate method, that can protect itself against multiple calls (i.e. if init has already happened, return immediately). That method will then be invoked by the virtual members and your constructor, before they rely on initialization having occurred.

It's a bit messy, and may represent a minor performance penalty, but there's little else you can do in VB.

Answer 2

Any well-written class must either ensure any virtual members which could possibly be invoked on a partially-constructed instance will behave sensibly. C# takes the philosophy that a class instance whose field initializers have run will be in a sufficiently-sensible state to allow virtual methods to be used. VB.net takes the philosophy that allowing field initializers to make use of a partially-constructed object (and--with a little work--any parameters passed to the constructor) is more useful than a guarantee that field initializers will run before any virtual methods are called.

IMHO, the right approach from a language-design standpoint would have been to provide a convenient means of indicating that specified field initializers should be run "early" or "late", since there are times each can be useful (though I prefer the "late" style, since it allows constructor parameters to be made available to field initializers). For example:

Class ParamPasserBase(Of T) ' Generic class for passing one constructor parameter
  Protected ConstructorParam1 As T
  Sub New(Param As T)
    ConstructorParam1 = Param
  End SUb
End Class
Class MyThing
  Inherits ParamPasserBase(Of Integer)
  Dim MyArray(ConstructorParam1-1) As String
  Sub New(ArraySize As Integer)
    MyBase.New(ArraySize)
  End Sub
  ...
End Class

In C#, there's no nice way to have field declarations or initializers make use of arguments passed to a constructor. In vb, it can be done reasonably cleanly as illustrated above. Note that in vb, it's also possible to use a by-reference constructor parameter to smuggle out a copy of the object under construction before any field initializers are run; if a class's Dispose routine is properly written to deal with partially-constructed objects, an object which throws in its constructor can be properly cleaned up.