What is the thinking behind records not requiring all properties to be initialized, yet complaining about non-nullables?

[reinux]

Coming from F#, this doesn't make much sense to me:

public record User
{
  public string FirstName { get; init; } // warning CS8618: Non-nullable property 'FirstName' must contain a non-null value when exiting constructor. Consider declaring the property as nullable. 
  public string LastName { get; init; } // warning CS8618: Non-nullable property 'LastName' must contain a non-null value when exiting constructor. Consider declaring the property as nullable. 
  public string EmailAddress { get; init; } // warning CS8618: Non-nullable property 'EmailAddress' must contain a non-null value when exiting constructor. Consider declaring the property as nullable. 
}

...

new User  // no errors, no warnings
{
}

It seems that if you have non-nullable fields, the only way to make this right is to use a constructor, which then disallows object initialization syntax, and brings it half way back to just being a class with readonly fields again (except it allows using with to do updates).

In F#, you receive an error if in the object initialization you don't specify all fields. That way there's no reason for it to warn about unassigned non-nulls.

What's the reasoning behind this weird, seemingly self-defeating behavior? Am I doing something wrong?

Might it make sense to remove the CS8618 warning for record fields when the record has no constructor, and instead warn if in the object initialization, a (non-nullable) property isn't assigned to?

[acaly]

I guess once we have the required initializer this should be solved.

#3630

[Joe4evr]

What's the reasoning behind this weird, seemingly self-defeating behavior?

The reasoning is that declaring a property to be non-null and initialization at the construction site are two orthogonal concerns.

[DavidArno]

It is because init is a simple compiler "trick" addition to properties. If you view the IL of the following:

public record R
{
  public string X { get; init; } 
}

you'll see that it still declares a set_X method as it would do if you used public string X { get; set; }, but the compiler then prevents you calling that setter except during construction and initialisation.

The C# team take a iterative approach to adding such features. As @acaly says, the next step in the process is to add some sort of "required properties" feature:

public record User
{
    public string FirstName { get; required init; } 
    public string LastName { get; required init; }
    public string EmailAddress { get; required init; }
}

At which point, you should no longer get those null warnings and you should get errors with:

new User { }

If this seems a back to front approach, welcome to the whacky world of C# where "hills of success" are favoured over "pits of success" all too often. 🤷

[HaloFour]

TLDR: records and NRTs are 100% orthogonal. NRTs are both optional and designed very intentionally to have no effect on the behavior of the code other than to generate diagnostics. Records need to compile and behave identically with or without NRTs enabled.

Required properties should alleviate some of the issue here as that should move the warning to the site of consumption. Required properties would give you a warning if you do not set the property, and NRTs, if enabled, would give you a warning if you set the property to a possibly-null reference. The compiler could then drop the diagnostic at the declaration site.

[acaly]

Are you saying that since required, nullable property is useful, we should give a warning to anyone using required, non-nullable properties? Does that make any sense?

[jnm2]

I'm not making the point but restating someone else's, but I'll give it a shot. I think the point is that since all four combos are useful, non-nullability should not imply requiredness, and nullability warnings for uninitialized, nonrequired, non-nullable members are just as valid and necessary as before.

[acaly]

No. You are again mixing required and initialized. Yes, requiredness and nullable types are orthogonal, but requiredness isn't part of the original question. If there were required feature, the author would use it for that property and the compiler should no longer give that warning at declaration site. The issue here is there is no such thing as required yet. What they claimed was that nullables and initialized are orthogonal, but you should never have something to be non-nullable and non-initialized for too long.

[jnm2]

You are again mixing

I'm not sure what 'again' means since this was my first try, so I'll bow out because I can see I'm just confusing the issue. What I came to say was that I don't think "orthogonal" means "stop asking questions that relate these two things."

[acaly]

Sorry I did not mean you, but I have mentioned the difference of this already. #4857 (reply in thread)

The point is, @CyrusNajmabadi claiming nullables and initialized are orthogonal is just wrong. If they are orthogonal, the compiler won't have that warning. The author did not make a mistake of "conflating" things together by asking this question.

[theunrepentantgeek]

It is like "these two features do not and will never touch each other and so don't ask any more".

If that's the meaning you took, then I expressed myself poorly.

What I've been trying to say is "These two features are not the same feature, and so please stop asking for them to be the same feature."

@acaly, you wrote:

Instead of leaving uninitialized properties (or variables) null, the language or runtime can instead implicitly set the non-nullable properties to some internally created objects, which throw something like a ObjectNotInitializedException upon accessed.

This reads to me as trying to get the compiler to enforce some kind of requiredness as a part of the nullability feature - trying to bring in requiredness by stealth.

The nullability (or not) of a property cannot be used to reliably infer the requiredness (or not) of that property.

I understand that you have a very common scenario where nullability and requiredness are very closely related. There are a lot of people who have that scenario, and this is why the C# LDM are designing/implementing requiredness.

But, and this is important: There are valid, useful, and common scenarios where a non-nullable property is not required.

The CS8618 warning is correct - and like every other warning in C#, it's up to the developer to decide whether to fix it (warnings are, after all, not errors), and further how to fix it.

The warning is telling the developer that there's something missing here. Either the constructor needs to be modified to assign a value, or it needs to be assigned during initialization, or the warning can be suppressed, or the warnings can be ignored.

[acaly]

OK, but the original post asks for a thinking behind the design. First, that is not to say they are the same feature. Second, it does not answer the question of "what is the thinking behind A and B" by saying "A and B are two features".

I agree that non-nullable, non-required property has its use case. The problem is, then we have to write a constructor and set to it some valid value. If no valid value is known, it has to use a constructor parameter, which eliminates all the advantages of init accessor. (By the way, your example does not have a non-nullable, non-required property.)

[acaly]

The nullability (or not) of a property cannot be used to reliably infer the requiredness (or not) of that property.

The are 2 different levels of requiredness: (1) whether the property or variable should be initialized, (2) whether the property or variable should be initialized externally by consumer.

For (1) we (and the compiler) can infer from non-nullability in that non-nullables must be initialized somewhere. They are related. For (2), I agree that, we can't infer (2) from non-nullability, but we don't have this concept of (2) yet in the language. So you can't really say they are totally unrelated until we have (2).

[DavidArno]

@theunrepentantgeek,

... The warning is telling the developer that there's something missing here ...

And that thing that is missing is required. There are too many here that have simply rushed to declare records and init properties as being orthogonal to each other when in reality they are clearly interrelated. There are four combinations of nullable/optional for properties and for one of them (non nullable and mandatory) not only is it unenforceable, but it gives a warning that has to either be ignored or suppressed.

I think there is often too much of a rush to declare the question invalid and to shut the questioner down in discussions here. And this question is a classic example of that happening. The answer to the question of why does the problem of mixing NRTs and records exist isn't "they are unrelated; there isn't a problem" and it's deeply unhelpful that some offered that as a response, especially since it is a false response. The truth is - for good or bad - the decision was made to partially develop record functionality and that left this functional hole. In time it be filled by required and the problem will go away, but it simply has to be worked around in the meantime. Sometimes just being open and honest is the simplest solution.

[jnm2]

I think programmers are particularly susceptible to overusing and abusing pet jargon like "orthogonal" or "conflate" and it can have a cold effect on the conversation. I see this even when the term is being used properly and people aren't just leaping to it too soon as a conversational move that feels good.

[jnm2]

The are 2 different levels of requiredness: (1) whether the property or variable should be initialized, (2) whether the property or > variable should be initialized externally by consumer.

For (1) we (and the compiler) can infer from non-nullability in that non-nullables must be initialized somewhere.

@acaly I think I see a clarification. If the compiler were to infer your "level 1" requiredness but then elevate it to "level 2," that would be an API change that should be annotated and locked in explicitly using a keyword like required so that your API doesn't fluctuate implicitly based on indirect changes to the private implementation. When that keyword doesn't exist, the compiler still shouldn't elevate it to "level 2," but it would be a foot gun for it to neglect to warn that there might be a null in the field marked as never null. I see only one option for the compiler when a required keyword is not used (or doesn't yet exist), and that is the current behavior.