Added: Notes for September 16th, 2020

[333fred]

https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-09-16.md

Agenda

• Required Properties
• Triage

[Joe4evr]

Very happy to see Required Properties having been discussed. I think most programmers would be fine with compile-time only warnings since it's primarily about moving the "uninitialized field" warning from NRTs from the declaration-site to construction-site.

Interesting point about factory methods, tho. Perhaps a bit more attribute-language is needed for that space, but that seems easy enough.

[YairHalberstadt]

A read of the room found that most of the LDM was leaning towards compile-time only validation of required properties. It does mean that upgrading binary versions without recompiling can leave things in an invalid state, but the implementation strategies for getting actual runtime breaks are very complex and we're not sure they're worth the tradeoff.

If required properties are checked at runtime as well as compile time, what's the advantage of required properties over constructor parameters? Adding a required property would be a binary breaking change.

[333fred]

what's the advantage of required properties over constructor parameters?

The ability to not have to restate those parameters at least twice in every derived class, and to not have to modify the derived classes that really don't care about the parameters, they just want to add new ones. Note that regardless of whether it's a runtime break, adding a new required property will be a source break. The question is just whether we try and make it so that the runtime behavior for such a change is deterministic, or non-deterministic.

[bbarry]

If the runtime behavior is not required, you can't really trust the value to have been set within the class and it is only good for analyzers from an external scope.

That could be confusing behavior to many developers who are not keeping up with the intricacies of the runtime.

[333fred]

That could be confusing behavior to many developers who are not keeping up with the intricacies of the runtime.

Well, it would be about as guaranteed as nullable is today. We do have precedent for this level of compiler-requiredness in the language, so I don't think that it would be a huge surprise. That being said, the purpose of this investigation was to see if we could come up with a runtime scheme for enforcement. If you have ideas on how such a scheme might be constructed, I'm all ears :).

[bbarry]

I can't say I have any really good ideas there. I'm all for the compile-time-only approach myself and not wasting my cycles on an initialization check that would be necessary on every access...

The only solution I can come up with would be something like this:

public sealed class LoweredClassWithRequiredProperties {
  object _locker = new object();
  uint _requiredBits = 0x3;
  int _foo;
  int _bar;
  // public int Foo { get; req init; }
  [Required]
  public int Foo {
    get {
      if (_requiredBits != 0) { throw new SomethingNotInitializedException(); } // lowered required
      return _foo;
    }
    set {
      lock (_locker) {
        if ((_requiredBits & 0x1) == 0) { throw new AlreadyInitializedException(nameof(Foo)); } // lowered init
        _requiredBits -= _requiredBits & 0x1; // lowered required
        _foo = value;
      }
    }
  }

  // public int Bar { get; req set; }
  [Required]
  public int Bar {
    get {
      if (_requiredBits != 0) { throw new SomethingNotInitializedException(); }
      return _bar;
    }
    set {
      lock (_locker) {
        _requiredBits -= _requiredBits & 0x2;
        _bar = value;
      }
    }
  }
}

This gets extraordinarily harder when considering inheritance.

[333fred]

Yeah, that's about where my proposals ended up as well.

and not wasting my cycles on an initialization check that would be necessary on every access...

That's actually one of the advantages of the static contract checks version, because you could put it in a static constructor and only check that the expected contracts are still valid once. But then there are definitely people who will avoid it because it will add a static constructor, and tracking requires those extra bits that some people won't want to put in their structs... We just haven't seen a good runtime encoding of this yet :(