Timeline for Option type in C# and implicit conversions
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 29, 2014 at 1:37 | history | edited | Jamal | CC BY-SA 3.0 |
deleted 50 characters in body
|
| Dec 29, 2014 at 1:36 | history | rollback | Jamal |
Rollback to Revision 3
|
|
| Jul 16, 2014 at 18:21 | comment | added | Mauricio Scheffer | You could just use sourceforge.net/projects/sasa or github.com/NICTA/xsharpx or github.com/fsprojects/fsharpx , etc... | |
| Feb 10, 2013 at 17:07 | vote | accept | Patryk Ćwiek | ||
| Feb 9, 2013 at 11:45 | comment | added | Patryk Ćwiek |
@svick Oh, good to know. Although the F# Option is nicely packed in a form of discriminated union, which I don't know how to express in C#, hence I went with Scala's version (although I see it works the same). I have added an edit with modified reference type and a new value type, I guess the value type Option looks better, although I like the semantics of reference Option... :)
|
|
| Feb 9, 2013 at 11:40 | history | edited | Patryk Ćwiek | CC BY-SA 3.0 |
added 8 characters in body
|
| Feb 9, 2013 at 11:34 | history | edited | Patryk Ćwiek | CC BY-SA 3.0 |
Added modified versions
|
| Feb 9, 2013 at 9:30 | answer | added | CodesInChaos | timeline score: 4 | |
| Feb 8, 2013 at 17:30 | comment | added | svick |
@Trustme-I'maDoctor F# does something similar: there, Option<T> is a reference type and null is used as the value representing None.
|
|
| Feb 8, 2013 at 17:17 | comment | added | C. A. McCann |
The Option names are certainly more traditional, and probably make more sense in C# than the Maybe naming scheme (and I say that as someone very familiar with Haskell and its influence on C#). Also, some people really don't like calling extension methods on a null reference, in which case a struct is the only reasonable choice.
|
|
| Feb 8, 2013 at 15:47 | comment | added | Patryk Ćwiek |
@svick By the way, I was curious and I checked: scala > val opt : Option[Int] = null works, and then opt.getOrElse(2) throws NullPointerException, so I guess it works in the same way :) You have a point though, maybe that's why implementations from almaz' answer use extension methods on reference types and work with nulls instead...
|
|
| Feb 8, 2013 at 14:54 | answer | added | almaz | timeline score: 2 | |
| Feb 8, 2013 at 14:13 | comment | added | Patryk Ćwiek |
Yeah, I guess struct would indeed be a better fit, and it would automatically alleviate the problem of the Option<T> being null itself. As for nullable, that's true, Option its superfluous for value types, but reference types can sometimes be a pain with null checks... I can't really say anything about the naming, I'm just more used to ML conventions, as I have dipped my toes in both F# and Scala, but not Haskell. :)
|
|
| Feb 8, 2013 at 13:55 | comment | added | C. A. McCann |
Usually when I see people doing this, they make it a struct instead of a class. Also, for some reason the Haskell-ish names Maybe, Just, Nothing seem more popular in C# implementations than the ML-ish Option, Some, None as seen in Scala and F#.
|
|
| Feb 8, 2013 at 13:35 | comment | added | svick |
Also, I think you should consider that C# already has idiomatic way to do this: null for reference types and Nullable<T> for value types. What's worse a variable of type Option<T> can still be null, so your type doesn't really work like true Option.
|
|
| Feb 8, 2013 at 13:28 | history | edited | Patryk Ćwiek | CC BY-SA 3.0 |
added 8337 characters in body
|
| Feb 8, 2013 at 10:28 | history | edited | Patryk Ćwiek | CC BY-SA 3.0 |
Grammar fixed + punctuation
|
| Feb 8, 2013 at 10:13 | history | asked | Patryk Ćwiek | CC BY-SA 3.0 |