Structure All Nullable Values
.NET Framework already has Nullable<T> but it could also have ToNullable<T> as a struct.
If you wanted to keep reference-types null and turn value-types to null you could make this:
T? value; /* = Nullable<T> value; but this gives error
because T may already be null */
T$ value; /* = ToNullable<T> value; this doesn't give error,
what you wnat is keep what's null null,
and turn non-null into null */
The only problem is that this does not exist!
If you don't understand anything about this, contact firstname.lastname@example.org.
Uh .. to me, this is one of those things that if you really, really need it .. you can write yourself. It looks like a 'edge case' kind of functional programming construct, that many will not have a lot of use for .. . Also, since everything in C#, all expressions anyway, evaluate to a type .. this sort (something like an 'option type' for example) sort of goes against that philosophy. Just my .02
"you can't put reference values into a Nullable<T>". Yes, I knew that, yet my objective was to enable Nullable<T> to do so, by making changes to the CLR.
I'm now using Nullable<Option<T>> value;.
Thank you for your help!
I have already posted this in http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/2cb7f451-bd56-480d-970b-ddb241889099.
Should I remove this idea since it is now proved to be a question?
Mauricio Scheffer commented
@JMCF125 : you can't put reference values into a Nullable<T>. That's why you need a separate type called an 'option type'.
For Sasa, see http://sasa.hg.sourceforge.net/hgweb/sasa/sasa/file/7815867ea6fa/Sasa/Option.cs
For FSharpx, see https://github.com/fsharp/fsharpx/blob/master/tests/FSharpx.CSharpTests/OptionTests.cs
Or post a question on stackoverflow.com
I really need this.
I've been stuck from progress for a long time.
I'm yet trying to find this miraculous ToNullable<T> type.
Thank you Mauricio.
I want to use SASA butI can't find this ToNullable type. Is there any manual or something I could use to find it?
Mauricio Scheffer commented
I think you're looking for an option type. It's very simple to implement but you can just get it from libraries like Sasa ( https://sourceforge.net/projects/sasa/ ), Functional-dotnet ( http://code.google.com/p/functional-dotnet/ ) or the F# runtime (FSharpx adds sugar for C#/VB.NET: https://github.com/fsharp/fsharpx )
More importantly, option types are composable and simple to use and understand. They don't require any modifications to the language or the type system.
That's what I wanted: "use Nullable<T> without regard for the type of T". Of course "HasValue" property would be changed too.
What would break if Nullable<T> simply didn't care whether it was used redundantly? Unboxing a string to a Nullable<string> should copy the reference to the internal "value" field, and set "HasValue" according to whether the reference is non-null. Unboxing a string to a Nullable<Nullable<string>> could do likewise, but setting both "HasValue" fields appropriately. The "HasValue" field would be largely redundant, but a lot of generic code could be cleaner if one could simply use Nullable<T> without regard for the type of T.
David V. Corbin commented
I have used similar patterns, but they are not bulletproof, and to the best of my knowledge, can not be made 100% bullet proof AND have equivilant performance without CLR changes (or at least language changes to access CLR functionallity).
This is something I need, and I haven't found a solution.
The problem is posted in this forum:
Take a look and comment either here or there what you think.
I used the $ sign to show ToNullable<T> could be used as Nullable<T>, however another symbol, like § could be used.
In my example, I wanted to make sure value is nullable, but I don't know if it alredy is. If it is, nothing changes, if it isn't, it is turned into nullable.
Nullable<T> gives error, because the value may alredy be null, so I'd use ToNullable<T>, that makes sure the value is null. Therefore, I can assign the value to null.
This reminds me of the C++/CLI feature where you can access boxed structure members directly, without unboxing. It would be neat if you could somehow tell the compiler that you want to use a boxed value type without losing its type identity. I'm not quite sure why they invented Nullable<T> when the CLR has had the built-in ability to convert value types into (nullable) reference types since v1.0.
I could think of better uses for a dollar sign, though. If they hadn't already used "?" for nullable types, it seems like it would have been ideal for what you are suggesting. Imagine if "int?" were still a nullable int (a boxed int if not null), and T? would be a reference type OR a boxed value type.
This has some ortografic errors, but I can't edit them.