Discussion: Should we allow struct types to overload cast operator to their nullable counterpart in user code?

[stackh34p]

I am creating this suggestion in relation to the following issue. I came up to this point trying to implement a use-case I've asked about in Stackoverflow

In the particular use case I was creating a Nullsafe<T> struct type that would be analogical to the System.Nullable<T> type, but the underlying type is instead a reference type. Long story short, I wanted to reduce unnecessary code when expressions like Nullable<Nullsafe<T>> are encountered. Typically, I should use GetValueOrDefault() if I want to pass an instance of Nullable<Nullsafe<T>> to a method expecting just Nullsafe<T>.

So, I attempted add an implicit cast, which the compiler did not allow me to.

public static implicit operator Nullsafe<T>(Nullable<Nullsafe<T>> nv) => nv.GetValueOrDefault();

Below is the error thrown by the compiler that lead to creating this thread:

error CS0555: User-defined operator cannot take an object of the enclosing type and convert to an object of the enclosing type

The message is not really correct, as it is a result of intentional erasure of the nullable type done by the compiler.

By opening this issue, I'd like to see whether there is a point of allowing developers to define cast operators to the nullable counterparts of their own user-defined struct types.

I believe in use-cases like mine, that would be beneficial, as any value of Nullable<Nullsafe<T>> would be semantically identical to the underlying Nullsafe<T> value. Allowing a cast from Nullable would simplify some cases, as for instance methods accepting a Nullsafe<T> as arguments would implicitly accept instance of T, Nullsafe<T> and Nullable<Nullsafe<T>> if the appropriate cast operators are defined.

On the other hand, the Nullable<T> type itself is, without any doubt, designed to not implicitly disclose its underlying value. In case this behaviour should be enforced to all user-defined types, it would be better to have a more-direct error message, such as "User-defined operators cannot take an object of the enclosing type and convert to an object of the enclosing type or a nullable wrapper of the enclosing struct type". The point is that the message must specifically address the case where nullable wrappers cannot be used as operands.

[svick]

Is there a use case other than improved handling of nullability of reference types? Because I don't think it makes sense to add a feature that would be effectively obsoleted by nullable reference types (#36, currently planned for C# 8.0).

[stackh34p]

I must admit, the discussion about nullable reference types was unknown to me until now and is quite big so I haven't thoroughly examined it. For the most part I would focus on this section:

... For instance, accessing .Value on a Nullable could produce a warning if the value was accessed without checking for null first. An even more advanced extension would allow Nullable values to be accessed without going through .Value if the variable is proved to not be null. ...

If I read that correctly, the compiler will allow user code to skip the .HasValue / .Value accessors on a value-type Nullable<T> if it is known to not be null. If so, this would elliminate the need for overloading the cast operator in most cases.

[bruce965]

Minor note: allowing this overload could permit to implicitly cast IntPtr? to IntPtr.

public readonly struct IntPtr // ...snip...
{
	public static readonly IntPtr Zero;

	// ...snip...
	
	public static implicit operator IntPtr(IntPtr? value)
		=> value ?? Zero;
}

Allowing the following code to compile:

// Cannot convert null to 'IntPtr' because it is a non-nullable value type. csharp(CS0037)
IntPtr ptr = null;

[333fred]

If I read that correctly, the compiler will allow user code to skip the .HasValue / .Value accessors on a value-type Nullable if it is known to not be null. If so, this would elliminate the need for overloading the cast operator in most cases.

It would have, had we not explicitly rejected it as too breaking of a change.