Nullable reference type in explicit interface implementation, warning CS8618

[ilbrando]

Is it a bug that the compiler can't figure out that Bar does get initialized in the constructor?

In the explicit interface implementation I get a CS8618 warning: Non-nullable IFoo.Bar must contain a non-null value when exiting constructor
When using implicit implementation there are no warnings.

How is nullable reference types supposed to be used with explicit interface implementations?

public interface IFoo
{
  string Bar { get; set; }
}

public class FooExplicit : IFoo
{
  public FooExplicit(string bar)
  {
    if (bar is null) throw new ArgumentNullException(nameof(bar));
    ((IFoo)this).Bar = bar;
  }
  string IFoo.Bar { get; set; }
}

public class FooImplicit : IFoo
{
  public FooImplicit(string bar)
  {
    if (bar is null) throw new ArgumentNullException(nameof(bar));
    Bar = bar;
  }
  public string Bar { get; set; }
}

Thanks for any help

[ilbrando]

I found a work around. Using a private field.

public interface IFoo
{
  string Bar { get; set; }
}

public class FooExplicit : IFoo
{
  private readonly string _bar;
  public FooExplicit(string bar)
  {
    if (bar is null) throw new ArgumentNullException(nameof(bar));
    _bar = bar;
  }
  string IFoo.Bar => _bar;
}

[CyrusNajmabadi]

I don't understand what you mean with this. If a subclass implements the interface it takes responsibility for the property and must ensure it has a value as it can't be null or am I missing something?

I'm saying that the assignment in your constructor will call into the subclass, and the backing field for your explicit interface will remain null and uninitialized. That's why the solution here is to use an actual property initializer as that's the only thing guaranteed to write into that property's backing field.

😊 I consider safe null handling part of type safety

It is not, and we do not.

and I want all my code to be safe.

You can write your own analyzers/suppressors to have this logic then. That is a stated non goal of NRT.

I feel I'm doing something wrong

You're not doing something wrong. You just have expectations that are counter to our explicit design goals for this feature.

or the compiler has some shortcomings.

Yes. The compiler has many limitations here. That's necessary as the analysis for this sort of problem is unbounded in scope, and extremely expensive. As such, we've made certain decisions to make sure we can do this work in a cost effective fashion while balancing the need for good true positives, and low incidences of false positives.

If you are ok with any amount of expense to get your definition of 'type safety', then that avenue is available with analyzers and suppressors.

[ilbrando]

I'm sorry, but i don't know what NRT means and I'm only trying to give my input on what I find to be good code quality and how I hope the compiler helps me in writing it. I have used TypeScript a lot for several years now and continue to be amazed at how they continue to improve type safety (in the way I understand the word).

[CyrusNajmabadi]

i don't know what NRT means

"Nullable reference types". The feature here that is saying "you declared this as non-null, but it may still be null at runtime".

and I'm only trying to give my input on what I find to be good code qualit

RIght. But we're telling you: write it in the following way. :)

You can choose to reject our suggestions, but then we're at an impasse.

I have used TypeScript a lot for several years now and continue to be amazed at how they continue to improve type safety (in the way I understand the word).

TS is much less typesafe than C#. Allowing, for example, types to be entirely different from what they are stated at compile time whne actually executing at runtime.

Our NRT impl is very similar to TS's similar approach to giving or avoiding null warnings. However, TS also doesn't have this concept of explicit interface implementation, so the comparison doesn't work here :)

[ilbrando]

I think this is going a bit in a wrong direction. I still think my original question is valid. Everybody can see the property is initialized in the constructor - except the compiler. It can be solved with a private field, but I don't need/want a private field, so this is kind of a work around, and it would be better if the compiler could infer what is happening exactly as it can in the implicit version.

[CyrusNajmabadi]

Everybody can see the property is initialized in the constructor - except the compiler.

It is not. The constructor is casting 'this' to an interface, which can and will write into some other property.

but I don't need/want a private field,

Then you can suppress the warning. We provide the tooling for a user to say: I know better about the entirety of my code, and there's no way this will ever write into something else, so please be quiet. :-)