Conditionally set properties in object initializers

[AArnott]

In MessagePack-CSharp/MessagePack-CSharp#1369 (comment) we discuss how it seems to be impossible to initialize an object's init properties conditionally. For a deserializer that needs to set these properties iff values for those properties appear in the serialized data stream, this presents a real problem for AOT generated deserializer code. I expect the System.Text.Json deserializer's new AOT code gen feature in 6.0.0 may suffer from the same problem.

For example consider initializing this object:

public class A {
  public int B { get; init; } = 3;
  public int C { get; init; }
}

Properties B and C can only be set with syntax like this:

A a = new A {
  B = 5,
  C = 2,
};

This is fine for hand-written code. But for an AOT code generated deserializer when values for B or C are optional, we would need something like this:

A a = new A {
  B = reader.ReadInt32("B"),
  C = reader.ReadInt32("C"),
};

But how would we make the assignments to B (and C) optional such that a missing value for B would allow the 3 default value to remain? I know of no way to conditionally call an init accessor. An alternative might be to invoke it with its existing value, but as there is no way to reference the object within its own object initializer, we can't do something like this:

A a = new A {
  B = reader.TryReadInt32("B", out int v) ? v : _.B,
  C = reader.ReadInt32("C"),
};

Above I hypothesize that _ is a reference to the initializing object, but this isn't valid C# 10 code.

Do we need a new feature for this?

[CyrusNajmabadi]

Definitely seems like an interesting case. i presume the following are not viable:

var readB = reader.TryReadInt32("B", out int b);
var c = reader.ReadInt32("C");;
A a = readB ? new A { B = b, C = c } : new A { C =c };

Presumably this would be bad because of combinatorics.

Alternatively, could you make a private static readonly A s_defaultA = new A { }; somewhere? Then, you could write things as:

A a = new A {
  B = reader.TryReadInt32("B", out int v) ? v : s_defaultA.B,
  C = reader.ReadInt32("C"),
};

This also seems unpleasant (and quite possibly unsafe if there's shared mutable data?). But i'm just spitballing ideas to see if there's something possible that's palatable. If not, then it does seem like we might need something here.

[AArnott]

Presumably this would be bad because of combinatorics.

Ya. Many objects we see using our deserializer have dozens of properties. That wouldn't scale.

Alternatively, could you make [static object template]

That's certainly an interesting idea, however it assumes a default constructor exists, and deserializers often support classes without a default constructor by passing in arguments whose names match properties we have values for.

[CyrusNajmabadi]

That's certainly an interesting idea, however it assumes a default constructor exists, and deserializers often support classes without a default constructor by passing in arguments whose names match properties we have values for.

Could you pass default in those cases? or could that potentially throw because the types have invariants on the values for those parameters?

[JPaja]

That's certainly an interesting idea, however it assumes a default constructor exists, and deserializers often support classes without a default constructor by passing in arguments whose names match properties we have values for.

Could you pass default in those cases? or could that potentially throw because the types have invariants on the values for those parameters?

I would go against default keyword, because that would mean zero value

[AArnott]

We generally have no idea what the impact of those arguments would be, or what values would lead the constructor to throw validation errors. I also don't know whether these args would influence the default values of the properties so that they would match the default value they would be for the object I'm deserializing when I have "real" values for the deserializing constructor.

[JPaja]

What about allowing if statement in initialization block
like

A a = new A {
  if(reader.TryReadInt32("B", out int v))
     B =  v,
  C = reader.ReadInt32("C"),
};

[JPaja]

just there is issue what when we have 2 when cases

A a = new A
{
    B when expr1 = 1,
    B when expr2 = 2,
    C = c
};

where both expressions are true should it pick 1 or 2
also another problem would be

A a = new A
{
    B when reader.TryReadInt32(out int b) = b,
    B when reader.TryReadInt32(out int b) = b,
    C = reader.ReadInt32()
};

should it evaluate second read function
because it could affect what is returned returned in C

[AArnott]

Personally I would guess that every expression that returns true would result in an assignment, made in the order specified in the object initializer. So in your example, if expr1 and expr2 were both true, then B would be set first to 1 then to 2.

[AArnott]

@CyrusNajmabadi How do we move this proposal forward?

[AArnott]

I filed #6117

[333fred]

@AArnott the next step is to find a member of the LDT that is willing to champion the proposal.

[YairHalberstadt]

A different solution would be to allow setting init properties until the value is first read. Then you could do:

A a = new A {
  C = reader.ReadInt32("C"),
};

if (reader.TryReadInt32("B", out int v)) 
{
    a.B = v,
}

But this would be illegal:

A a = new A {
  C = reader.ReadInt32("C"),
};

Use(a);

if (reader.TryReadInt32("B", out int v)) 
{
    a.B = v,
}

[333fred]

So, I agree that's the only way it could be spec'd, but it definitely plays into my fears about obviousness. If it's "always after the object creation expression ends", it's very simple to reason about. If it's "just before the object is read", then I get very nervous about unexpected effects.

[YairHalberstadt]

I do see that, but I think in practice that's unlikely to be an issue. It generally won't matter when it's run, so long as it's before it's used. Nobody should be relying on exceptions thrown from validator for behaviour, so it should only matter for maintaining invariants, for which before first use is sufficient.

[CyrusNajmabadi]

If it's "just before the object is read", then I get very nervous about unexpected effects.

Especially... what if it's never read! (and someone has the validator run some final code that they use for the side effects) :-/

[YairHalberstadt]

I would say that we should guarantee it always runs at some point, but definitely before it's read.

[SAM-tak]

This approach looks good.
However, considering why the init attribute was needed, I think the assignable period should still be lexical scope.

A a;
if (exp) {
  a = new A {
    C = reader.ReadInt32("C"), // OK
  };
  if (reader.TryReadInt32("B", out int v)) 
  {
      a.B = v;  //OK
  }
}
if (a != null) 
{
     a.A = 0; // the first explicit assignment for A but illegal
}

A CreateA()
{
  var ret = new A();
  ret.B = 0; // OK
  return ret;
}

vae a = CreateA();
a.C = reader.ReadInt32("C"); // the first explicit assignment for C but illegal

[TahirAhmadov]

Another need I sometimes face:

var c = new Class
{
  A = 123,
  B = init.A + 10,
};

Here, I invented a keyword (similarly to OP's _) which in this context means "object being initialized". This is helpful in both object initializer scenarios, as well as anonymous type scenarios (this simplifies doing what let keyword does in LINQ queries, in the extension methods approach).

var res = 
  query
    .Select(p=>new 
    { 
      FullName = p.FirstName + " " + p.LastName, 
      FullNameAndSuffix = init.FullName + " " + p.Suffix 
    });

If we were to add this keyword, then OP scenario becomes possible:

var c = new Class
{
  A = int.TryParse(str, out a) ? a : init.A,
};

Basically, I think we can kill a few birds with one stone. I'm not stuck on init keyword - _ would be fine, too.
PS. The downside is that B is re-assigned for no reason; whereas with the when approach, it knows that it doesn't need to be assigned at all. This could be solved with special compiler logic: 1) virtually convert ternaries to if statements; 2) ignore all A = A; statements from the resulting "virtual" code.

[TahirAhmadov]

Alternatively, the default keyword could be used:

var c = new Class
{
  A = int.TryParse(str, out a) ? a : default,
};

This has the benefit that you're explicitly telling the compiler that there is no need to assign to that property. However, this solution addresses the OP question only and doesn't add the features I suggested above, like the init approach would.

[CyrusNajmabadi]

@TahirAhmadov that code is already legal today and has meaning. We could not change that meaning without potentially significantly breaking code.

[TahirAhmadov]

@CyrusNajmabadi the default one does?
PS. Oh right, brain fart, default becomes "zero" of the type. Scratch that.

[CyrusNajmabadi]

Yes. This is already legal. You can try it out today :)

--

Ah, just saw your edit :)

[AArnott]

It looks like System.Text.Json now could benefit from this as well with its source generator. Currently, they simply cannot support init property accessors: https://learn.microsoft.com/en-us/dotnet/fundamentals/syslib-diagnostics/syslib1037

[AArnott]

Also brought up on their own forum: dotnet/runtime#84484

[RikkiGibson]

It feels like if we do something for object initializers here, there should be space to expand it to other kinds of initializers and literals in the future, if desired.

_ = new Widget { Prop = value when (cond) };
_ = new Collection { A, B, C when(cond) };
_ = [A, B, C when(cond)];
_ = new[] { A, B, C when(cond) }

[jnm2]

On collection literals: spreading a conditional expression works by "accident" and it'll be very useful, but there could also be space for a less ascii-sneeze form of conditions/loops/etc as part of a more generalized initialization feature.

[AArnott]

[a, b, ..(cond ? [c] : [])].

What is this spread syntax I'm seeing? It doesn't work for me when I try it, and I've never seen it before in C#.

[333fred]

It will be part of collection literals.

[AArnott]

Ah, a future feature then. Thanks.

[jnm2]

(#5354)

[popcatalin81]

This could be a good use case for Lazy Initialized auto properties: #7145