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

OP said to not validate.

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.

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);

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.

With Zod: const info = z.object({ name: z.string().min(1), email: z.string().email() }

Have you seen ArkType (https://github.com/arktypeio/arktype)? Similar parse-based approach to validation with a significantly more concise definition syntax:

const info = type({ name: "string>0", email: "email" })

No, but I'm a heavy Zod user so ArkType it looks interesting. Thanks for the tip!

Are there any compelling reasons to switch apart from the difference in syntax?