3 ms·

You can have a ValidEmail type that performs all the checks on construction.

• Thaxll 4y ago
  OP said to not validate.
  • lkitching 4y ago
    The OP is contrasting between a 'validation' function with type e.g. validateEmail :: String -> IO () and a 'parsing' function validateEmail :: String -> Either EmailError ValidEmail The property encoded by the ValidEmail type is available throughout the rest of the program, which is not the case if you only validate.
  • mrkeen 4y ago
    That's fine. Validation would be: Email email = new Email(anyString); email.validate(); Parsing (in OP's context) would be: Either<Error, ValidEmail> eEmail = Email.from(anyString);
  • gnulinux 4y ago
    You're misunderstanding. Validation looks like validateEmail : String -> String -- post-condition: String contains valid email whereas parse looks like: parseEmail : String -> Either EmailError ValidEmail There is no problem using `ValidEmail` abstraction. The problem is type stability, when your program enters a stronger state at runtime (i.e. certain validations are performed at runtime) it's best to enter a strong state at compile time (stronger types) so that compiler can verify these conditions. If you remain at String, these validations (that a string is valid email) have no compile-time counterpart so there is no way for compiler to verify. So use `ValidEmail` instead.