Primary Constructors aren't consistent with regular constructors

[Statharas]

Version Used: 9.0

Steps to Reproduce:

https://sharplab.io/#gist:6e196059c74644a3962eb9b9ba08aabf

In the above snippet (albeit a bad practice) is an example of using the primary ctor that will introduce an inconsistency due to the ordering of the constructors.

As per the following explanation, this effectively doesn't share the same behavior as a regular ctor.

Given the above, the following example shows exactly why this happens:

Expected Behavior:

It is expected that a primary constructor would be able to replace a regular constructor

Actual Behavior:
The primary constructor does not have the same behavior as the regular constructor

[jaredpar]

As per the following explanation, this effectively doesn't share the same behavior as a regular ctor.

That is because they are different concepts. The samples here are trying to draw an equivalence between fields and parameters of a primary ctor. That equivalence though is incorrect as primary constructor parameters are a different concept than fields. Yes the mode of implementation is a field but the semantics of how the value works is not that of a typical field.

The primary ctor spec specifically guarantees that the value of a primary ctor parameter is available during instance member initialization. Essentially the following will print 42 not 0. That is because the value is available during member initialization and that occurs before the base ctor call.

Console.WriteLine(new C(42).M);
class C(int i) { 
  public int M = i;
}

The field examples in the repro assign fields after the base ctor call hence get differing behavior.

[Statharas]

As per the following explanation, this effectively doesn't share the same behavior as a regular ctor.

That is because they are different concepts. The samples here are trying to draw an equivalence between fields and parameters of a primary ctor. That equivalence though is incorrect as primary constructor parameters are a different concept than fields. Yes the mode of implementation is a field but the semantics of how the value works is not that of a typical field.

The primary ctor spec specifically guarantees that the value of a primary ctor parameter is available during instance member initialization. Essentially the following will print 42 not 0. That is because the value is available during member initialization and that occurs before the base ctor call.

Console.WriteLine(new C(42).M);
class C(int i) {
public int M = i;
}

The field examples in the repro assign fields after the base ctor call hence get differing behavior.

The regular ctor would also have the same behavior, though.

I don't see how that is an issue. In which instance would it print 0?

[ClxS]

To clarify something (I'm clxs/Akari in the screenshots above), it started out the above diagnosing a difference in behaviour. This difference is because I forgot about inline field initialisation 😉

Here is a more complete example which shows how the behaviour is fine, just unexpected if considering the pcotr a ctor, instead of the field init it (potentially) is.

https://sharplab.io/#v2:C4LgTgrgdgNAJiA1AHwAICYCMBYAUHgIQEMwACAI1IF5SoBTAdwApMAGASgG48AxAez6kAZtVqMWHbvlxFyAZ2BgiAY2CkMpYmGJy6eAN55Sx9QGZNJHXSbsjJw7hNPjqTAE4mAEgBE+gCp0CgC+3lx2zi7uXr4BCughYY4mQeGkqQAOYHzAdKp0cKSyCkqq6myksWr6pADmdMCcpClJxpnZuTkFRYoqaq6sFYHA6KTVdQ1NeM14GlpMAJZQakTspCAW2kS6Bk4ZWTl5BXwAbnRgYPNwdGUDldQAfIUAdH58AMqKizU2Uk5tB51SCczhcrjdBnEHs9Xh8LlBvolptINPxBOstFYDHt5sciDlSIs1AB9Ii/EyZHF4679YQCUTeNjeMmtfYdfJA07nS7U8p3KiPEkvd6feE/PbtQ4ckHc8GVEb82l8ZlpFpmUiohZLQq2VUOCLGEmiUmpZpBIA

[jaredpar]

I don't see how that is an issue. In which instance would it print 0?

The difference in how primary and regular ctor work with member initialization can only be observed when there is inheritance. That is because of how the initialization happens. Let me try and explain with a bit of pseudo-c# on what is happening here. Let's start by looking at the example you posted:

public class C {
  public int Field;
  public C(int f) { 
    Field = f;
  }
} 

Let's look at how the constructor is actually generated.

public C(int f) { 
  // the generated call to object.ctor call. There is always a base constructor call and in this 
  // case object is the base type so it's ctor is used
  base.ctor();
  Field = f;
}

Notice that the base constructor is running here before assignment to Field. Now let's look at the equivalent example using a primary ctor. Using D as the type name to help with readability of the diff samples:

public class D(int f) {
  public int Field = f;
}

Now let's look at how the constructor is generated.

public D(int f) {
  Field = f;
  // Same base.ctor call as before
  base.ctor();
}

Notice how in the primary ctor example that the assignment occurs before the call to the base constructor. That means it's visible (published) before other code in the constructor executes.

When the base type is object this difference is basically meaningless. But when the base type is a user defined type and the field / property is accessed in virtual methods then it becomes possible for the base type to observe the difference between these two approaches.