1

I am using C# 8.0 with nullable errors turned on.

I have a method in which the nullable property of the return type is set to something other than null. Both the return type and its property are going to be used so just returning the property is not an option.

public static T DoSomething<T>() where T : IMyInterface, new()
{
    T myObject = new T();
    myObject.NullableProperty = "Definitely not null";

    return myObject;
}

public interface IMyInterface
{
    string? NullableProperty { get; set; }
}

I have no control over IMyInteface.

Is there a way to inform the consumers of this method that the property is not null?

The documentation mentions the attributes MemberNotNull and MemberNotNullWhen, but these are for the members of the class of the method itself and not for the return value.

I could, of course, simply tell the compiler to forgive the nullability of the property when using the result of the method:

var result = DoSomething<MyImplementation>();
var length = result.NullableProperty!.Length;

but this seems like a hack and would require all consumers of the method to know they could trust the method to not return a property with a null value.

The other option is to use an out parameter on the method:

public static T DoSomething<T>(out string notNullResult)
    where T : IMyInterface, new()
{
    T myObject = new T();
    myObject.NullableProperty = "Definitely not null";

    notNullResult = myObject.NullableProperty;
    return myObject;
}

then it could be called as follows:

var result = DoSomething<MyImplementation>(out string notNullResult);
var length = notNullResult.Length;

but that would add extra parameters to the method and adds some confusion (the consumer would ask why can they use notNullResult but not result.NullableProperty).

somethingRandom
  • 811
  • 11
  • 16
  • Does this answer your question? [The annotation for nullable reference types should only be used in code within a '#nullable' context](https://stackoverflow.com/questions/55492214/the-annotation-for-nullable-reference-types-should-only-be-used-in-code-within-a) and [Best practice when using C# 8.0 nullable reference types with deserialization?](https://stackoverflow.com/questions/54902830/best-practice-when-using-c-sharp-8-0-nullable-reference-types-with-deserializati) –  Jun 01 '21 at 10:03
  • 1
    Not really, I have gone over the documentation on the nullable static analysis attributes but none of them work in this case. I will add a code snippet describing what I have already tried and what I'm trying to avoid. – somethingRandom Jun 01 '21 at 10:10
  • If you have no control over `IMyInterface` you have no control over the property either. In particular, the setter for `NullableProperty` could legally be implemented as something that ignores what you pass in and makes it `null` anyway. Not nice to do so, of course, but possible. Even if we want to discount that possibility, there is no way to make nullability statements about members of objects that you return, as opposed to the objects themselves (that I know of). `MemberNotNullWhen` can assert this for members, but only for the containing type. – Jeroen Mostert Jun 01 '21 at 10:18
  • Seems to me like you're fighting the default here -- would it be an option to just make the property *not* nullable and make exceptions for those cases where it is (hopefully just early in the object's lifetime)? This wouldn't work so well if clients can set the property to `null` at any time, but then that's a problem with the design anyway, in terms of safety. – Jeroen Mostert Jun 01 '21 at 10:31
  • @JeroenMostert I don't have control over the return type (it is part of a library I am using). The goal of the method is to initialise the object and give a value to the nullable property. Consumers of the method would then, ideally, be able to use the return object and its property without any warnings/errors. Unfortunately, there doesn't seem to be support for informing the compiler that a property is not null. – somethingRandom Jun 01 '21 at 10:36
  • 1
    Yes, my argument would be that the author of that type, if it is expected that the type spends the majority of its life with that property not `null`, might want to consider flipping the default as it's not helpful. If that's not an option, though, I think you'll just have to take the loss on this one. Static analysis can only go so far in any case. – Jeroen Mostert Jun 01 '21 at 11:00
  • Consider sharing your scenario in https://github.com/dotnet/csharplang/discussions/4563 – Rikki Gibson Jun 10 '21 at 00:36

0 Answers0