Nullable reference types about galaxus.functional HOT 4 CLOSED

Yeah, that's fine by me.

from galaxus.functional.

@phkiener This will not work because using T? requires T to be

1. either a value type
2. or a not nullable reference type

We usually just use T without constraints (Option<T> or Either<A, B>). The problem is that the compiler needs to know wether 1. or 2. is the case. And we cannot say which is the case because we always need both at the same time.

We can get around this issue by using the ! operator. But that negates the benefit almost completely. I think the overhead of doing this outweights the benefits.

See also:

• https://stackoverflow.com/questions/58229782/receiving-error-about-nullable-type-parameter-even-when-parameter-has-notnull-co
• https://stackoverflow.com/a/54594285/2173516

from galaxus.functional.

Damn, you're right. And the hole goes all the way down - even if we were to just annotate the entries to the abstractions (ToOption() and the likes), it would just spiral down like async does.

Still a shame though, they're a nice feature and something that could help when integrating. But it won't be worth it if we basically have to rework large parts... better accept it and know where stuff is null than introduce a bazillion breaking changes.

from galaxus.functional.

I feel like Microsoft should iterate on the design of nullable refs. Maybe we will see an improved version in a future C# version which is more flexible that the current design. One where we can use value and reference types interchangeably.

Shall we close the issue as won't do?

from galaxus.functional.