Validation (Result.tryCreate) about fstoolkit.errorhandling HOT 3 CLOSED

It's not possible to have SRTP with module functions. But I don't see why you would need that, because there's no SRTP involved in the current definition of the operators (they simply alias Result.bind etc.). So AFAIK your example should work correctly already (apart from the fact that you're calling the tryCreate functions with two parameters when your definition of them only accepts one parameter).

In other words: The right-hand side of the operator is a simple Result<_,_> value, not a type with a tryCreate function. The fact that the documentation currently uses static members called TryCreate is purely coincidental; it could just as well use functions such as you describe.

(Do let me know if I'm wrong; I don't have full knowledge of this library, but this fits with what I can observe.)

from fstoolkit.errorhandling.

@cmeeren I see your point, after looking into it a bit more, I noticed that I am not bound to using member TryCreate There are other ways to accomplish the same thing =)

Thanks for quick response =)

from fstoolkit.errorhandling.

Thanks, @cmeeren for jumping in.

@AlbertoDePena, The rationale behind the current implementation is based on this example https://demystifyfp.gitbook.io/fstoolkit-errorhandling/index/trycreate#example-1 in the documentation.

The overall idea was inspired by clojure.spec where each attribute type will have its own validation logic in the form a static member TryCreate and then compose these attributes to form different entities. By using the Result.tryCreate, we can leverage this individual attribute level validation across any entities.

from fstoolkit.errorhandling.