Earlier quoted context omitted.
In the spirit of "Parse, Don't Validate", rather than encode "validation" information as a boolean to be checked at runtime, you can define `Email { raw: String }` and hide the constructor behind a "factory function" that accepts any string but returns `Option ` or `Result `. If you need a stronger guarantee than just a "string that passes simple email regex", create another "newtype" that parses the `Email` type fur…
I would still usually prefer email as just a string and validation as a separate property, and they both belong to some other object. Unless you really only want to know if XYZ email exists, it's usually something more like "has it been validated that ABC user can receive email at XYZ address". Is the user account validated? Send an email to their email string. Is it not validated? Then why are we even at a point in…
> Is the user account validated? Send an email to their email string. Is it not validated? Then why are we even at a point in the code where we're considering emailing the user, except to validate the email.
You are looking at this single type in isolation. The benefit of an email type over using a string to hold the email is not validating the actual string as an email address, it's forcing the compiler to issue an error if you ever pass a string to a function expecting an email.
Consider function `foo`, which takes an email and a username parameter.
This compiles just fine but is a logic error:
void foo (char *email, char *username);
...
char *my_email = parse_input ();
char *my_user = parse_input ();
foo (my_user, my_email);
void foo (email_t *email, char *username);
...
email_t *my_email = parse_input ();
char *my_user = parse_input ();
foo (my_user, my_email); // Compiler error