You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While testing in #12 (comment), I noticed that I had to open separate namespaces to get the result and asyncResult instances, and yet another one (the main FsToolkit.ErrorHandling) to get the helpers (Result.xxx etc.).
I suggest that we make result and asyncResult available in the main namespace (perhaps other CEs too?). While I may be biased to my own usage, I guess that people using this library are very likely to want these builders, so we shouldn't require them to have three opens in every relevant file.
(I haven't investigated the rest of the namespace/module structure of FsToolkit.ErrorHandling; there might be other places we could simplify, too.)
The text was updated successfully, but these errors were encountered:
While testing in #12 (comment), I noticed that I had to open separate namespaces to get the
result
andasyncResult
instances, and yet another one (the mainFsToolkit.ErrorHandling
) to get the helpers (Result.xxx
etc.).I suggest that we make
result
andasyncResult
available in the main namespace (perhaps other CEs too?). While I may be biased to my own usage, I guess that people using this library are very likely to want these builders, so we shouldn't require them to have threeopen
s in every relevant file.(I haven't investigated the rest of the namespace/module structure of FsToolkit.ErrorHandling; there might be other places we could simplify, too.)
The text was updated successfully, but these errors were encountered: