If you can construct an EmailAddress, then you have a valid EmailAddress. That's the point.
If an EmailAddress can be a valid or invalid email address, then just leave it as a String (since that can also be a valid or invalid email address).
> You check that stuff when the data enters the system.
Yes
> If that place is the EmailAddress type, then you have built your system wrong.
No
If you validate & construct an EmailAddress from another external class, that means external classes are free to bypass validation and construct an invalid EmailAddress. Putting the validation/construction inside EmailAddress lets you force construction to go via validation.
My advice: Relax and don't argue. People who don't understand that constructing an EmailAddress type is also validating the raw email string (in this case) will never understand it. They'll remain convinced for a very long time, possibly the rest of their lives, that they know better. That passing a string around is fine as long as either you always validate it everywhere (yes, kill your performance, that's smart) or that they validated it once and they pinky swear to never change the value and to always call validate before passing it into the system.
Let them find subtle errors in their programs over time, it's job security for them. They don't want to move on to new and more interesting things they just want to keep fixing the same shit for the rest of their careers.
If an EmailAddress can be a valid or invalid email address, then just leave it as a String (since that can also be a valid or invalid email address).
> You check that stuff when the data enters the system.
Yes
> If that place is the EmailAddress type, then you have built your system wrong.
No
If you validate & construct an EmailAddress from another external class, that means external classes are free to bypass validation and construct an invalid EmailAddress. Putting the validation/construction inside EmailAddress lets you force construction to go via validation.