Fred Silberberg

> something that you would expect to be possible but it doesn't work merely because it's not implemented That's not how I think about this at all. Function pointers aren't...

To call it out more explicitly: we know we want to do something here, but we need to find a good syntax. I'm looking forward to seeing suggestions from the...

> `mustinit` seems redundant. My idea there was more ```cs public int Prop { get; must init; } ``` The full word was for if it's a modifier on the...

Updated the proposal with a new alternative section on "Initialization Debt", which builds on this proposal as a general way of communicating what properties must be initialized in a more...

> What's the reasoning being `init` props being non-mandatory? I may have missed something, but I imagine that they'll be very rarely used without a `req` modifier. @Richiban consider the...

It is an interesting scenario, and one I think could be covered by the initialization debt extension. In that world, those 3 things would be part of the debt, but...

> Therefore, let's start with the requirement that it is mandatory. That's what most people will expect it to be and that's what most people will want it to be...

> What about fields? The concept of initialization debt could certainly be extended to fields as well. > Whether a property is required may depend on which constructor is used....

> Still don't understand what the state of properties will be if they are not initialized even though they can only be set during initialization 🤔 It's going to be...

Seems like this would roll in with the general sealed type hierarchy proposals.