Caveat using Option<T>.Case (object) #952
Unanswered
StefanBertels
asked this question in
Q&A
Replies: 1 comment
-
I built these extensions methods to help me avoid type errors like the error above:
Replacing |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I stumbled upon a problem while using
Option<T>.Case
This feature was changed (returns object) in https://github.com/louthy/language-ext/releases/tag/v3.5.24-beta.
Look at this test:
This test will succeed. If you change the type of
x
, e.g. by adding another member code still compiles but test will fail:This is no suprise (different type => no match) but can cause undetected bugs if you use generics / type inference or for other reasons change one code line and forget to change the other line, too. IMHO we should avoid the need to have two identical (matching) type definitions (kind of DRY).
Having
object
here is even worse because analyzers (IDE) have no chance to produce a warning.Question: Is there a chance to improve here? Maybe using
T?
as return type forOption<T>.Case
?(Would be no option for Either etc.)
Should I void tuple types but declare custom types (classes/structs)? Any other idea/"solution"?
This is somewhat related to #939 (tuple matching).
Beta Was this translation helpful? Give feedback.
All reactions