[Thaxll]

OP said to not validate.

[lkitching]

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]

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]

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.