We are using our implementation of Optional<T> loosely derived from dotNetNext. We did that becuase it was uncertain at the time, whether this would make it into C# at all, and we didn't want the extra dependencies on the distributed library, not use some of the library classes.
We have some places int eh code where we are mapping between T? and Optional<T> and its very clunky.
We need more implicit conversations to make it more fluid code, and more discoverable for developers.
Secondly, ValudaObjectBase<T> dehydration is not really Optional<T> aware and that needs to change too.
We are using our implementation of
Optional<T>loosely derived from dotNetNext. We did that becuase it was uncertain at the time, whether this would make it into C# at all, and we didn't want the extra dependencies on the distributed library, not use some of the library classes.We have some places int eh code where we are mapping between
T?andOptional<T>and its very clunky. We need more implicit conversations to make it more fluid code, and more discoverable for developers.Secondly,
ValudaObjectBase<T>dehydration is not reallyOptional<T>aware and that needs to change too.