Remove Maybe type and change Option to be a readonly struct
See original GitHub issueThis is a major breaking change:
- Any code using
Maybe<T>
will need to change to useOption<T>
. - In line with the conversation in #51, the way
Option<T>
handlesnull
changes: i.Option<string>.Some(null)
will throw anArgumentNullException
. ii. As the type supports implicit casting ofT
toOption<T>
, castingnull
in this way will result in aNone
:
Option<string> x = null`
AreEqual(Option<int>.None(), result); // test passes
Issue Analytics
- State:
- Created 5 years ago
- Reactions:1
- Comments:5 (4 by maintainers)
Top Results From Across the Web
How can I create a privately-settable read-only struct (such ...
The Size type is a structure (value type), not a class (reference ... of the SomeSize property--it will only change the value of...
Read more >The 'in'-modifier and the readonly structs in C# - Developer ...
A readonly field of a reference type is like a constant pointer: the ... object's state may change (if the referenced type is...
Read more >Readonly members on structs (16.3, Core 3) · Issue #1710 ...
Today, users have the ability to create readonly struct types which the compiler ... you cannot mark the type as readonly (it would...
Read more >c# - Using readonly field instead of private setters in struct
I feel I prefer the current, field-based form, but maybe I am missing something... In case it does, which one is preferrable, regarding ......
Read more >Consuming Read-only Structs in C# | Pluralsight
First, we need to add the readonly keyword. But that alone is not enough. We also need to remove the set from the...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Well yes, I do. And having gone full circle, I’m re-opening this.
The reason I claimed that readonly structs are weird is due to the distinction between “read only” and “immutable”. In C#,
readonly
denotes that the value of that item cannot change. This means that I might have the class,The “value” of
_x
can’t change, ie it is fixed to referring to the sameList<int>
object. But the contents can change, ie it’s readonly not immutable.Readonly structs apply this same rule, but it creates odd results. So for example, the following code:
gives an error on
_x.a = value;
but not on_y.a = value;
. Further, despite marking it as readonly, I can still have setters. So I really struggled with the idea that it’s readonly as to me, that ought to rule out setters.But what I was missing is the simple idea that, just like with a readonly field, a readonly struct guarantees its value cannot change. And the value of a struct is the value of its fields. So the tuple, being a struct itself, cannot change the value of its fields as that would change its own value and thus the value of the struct,
S
. Likewise the reference for theFakeTuple
field can’t change, but items it contains can, as they aren’t part of the struct’s value. And setters are allowed, as long as they don’t change the value of the struct.So having had that lightbulb moment, I’ve gone back and re-introduced that readonly struct for
Option
. 😄Maybe<T>
is gone andOption<T>
is now a read-only struct.Closing as implemented.