This is intended as a discussion issue.
Some more combinators and utility methods on ParseResult to make it easier to chain and to work with would be helpful to me. I would primarily want the LINQ API and failure recovery combinators.
The LINQ API would allow using parse results in LINQ statements. For example something like
from localdate in datepattern.Parse(datestring)
from localtime in timepattern.Parse(timestring)
select localdate + localtime
yielding a ParseResult<LocalDateTime>
Filtering with a where clause would also be possible
from localdate in datepattern.Parse(datestring)
from localtime in timepatter.Parse(timestring)
where localtime > LocalTime.Noon && localdate.DayOfWeek == IsoDayOfWeek.Wednesday
select localdate + localtime
giving a success if the parse is for a Wednesday afternoon, and a failure otherwise. The where filtering would result in some less elegant results as it would require a natural zero for ParseResult, which would require an Exception to be pulled from thin air. On first sight creating something like a FilterException for that could work.
The Select and SelectMany methods would also be useful in their own right. Select is already implemented (as Convert), but has an internal access restriction. Nevertheless, the fact that it already exists suggests it's useful at least to the authors of the library.
For recovery options, it would be nice to be able to fold or project the error case. Some example method signatures on ParseResult<T>:
U Fold<U>(Func<T, U> success, Func<Exception, U> failure) //could be implemented as Success ? success(Value) : failure(Exception)
T Recover(Func<Exception, T> recovery) //could be implemented as Fold(identity, recovery)
ParseResult<T> TryRecover(Func<Exception, ParseResult<T>> recovery) //could be implemented as Fold(t => ForValue(t), recovery))
T ValueOrElse(T fallback) //could be implemented as Recover(ignored => fallback)
Writing these kinds of combinators isn't currently possible for users of the library, since ParseResult is sealed, and it's not possible to construct a ParseResult manually, neither for the success of failure, since the factory
Is there interest in something like that? If there is, I wouldn't mind seeing if I can put that together in a working demo, so the merits of the thing can discussed with actual code behind it.
This is intended as a discussion issue.
Some more combinators and utility methods on
ParseResultto make it easier to chain and to work with would be helpful to me. I would primarily want the LINQ API and failure recovery combinators.The LINQ API would allow using parse results in LINQ statements. For example something like
yielding a
ParseResult<LocalDateTime>Filtering with a
whereclause would also be possiblegiving a success if the parse is for a Wednesday afternoon, and a failure otherwise. The where filtering would result in some less elegant results as it would require a natural zero for
ParseResult, which would require anExceptionto be pulled from thin air. On first sight creating something like a FilterException for that could work.The
SelectandSelectManymethods would also be useful in their own right.Selectis already implemented (asConvert), but has aninternalaccess restriction. Nevertheless, the fact that it already exists suggests it's useful at least to the authors of the library.For recovery options, it would be nice to be able to fold or project the error case. Some example method signatures on
ParseResult<T>:Writing these kinds of combinators isn't currently possible for users of the library, since
ParseResultis sealed, and it's not possible to construct aParseResultmanually, neither for the success of failure, since the factoryIs there interest in something like that? If there is, I wouldn't mind seeing if I can put that together in a working demo, so the merits of the thing can discussed with actual code behind it.