Thank you for responding. I never said either that you are "normalizing away" the +bar thing, but that you are building in a non-standard convention to parse s

Thank you for responding. I never said either that you are "normalizing away" the +bar thing, but that you are building in a non-standard convention to parse semantics of an email address which (mostly) hold true for one particular provider (gmail.com), without at all acknowledging that this is gmail-specific. Even if you are aware of it, your readers might not be. In short, I do agree that your examples are silly, but I disagree that you demonstrate how they can do useful things: you mostly show how you can do silly things with them instead. Note that you are suggesting this as a pattern: even if your users are accustomed to their email addresses being normalized, they might not be accustomed to other things being so. If one takes your advice, you'd have a FullName, FirstName, LastName types as well which does the normalization based on the language, and using eg. Unicode NF. I do agree that you should do the things that have value, but I don't see you showing that value anywhere (as your example has a bunch of problems I highlighted, yet the benefits are?). Note that I've been there as well early on in my career: it feels so satisfying to imagine a world where our data types smartly represent exactly the object they need to, with all the properties and actions one can do with it. However, it quickly breaks up in the real world, and you end up with IncomingEmailAddress, SMTPEnvelopeEmailAddress, UserProvidedEmailAddress etc instead. This is not to say that if you've got a specific application that does some smart handling of an email address (like having aliasing rules for different popular providers) — eg. a mailing list app — but if that's not your business domain, a string is usually a better choice for what is essentially a string. Let me give you another simple yet convoluted example that usually quickly breaks: compund types (even your EmailAddress would be used in different contexts). For simplicity, let's go to my example of Name: (FirstName, LastName). For display purposes, you might want to show Name as "<FirstName> <LastName>" on a profile page (except for East Asian names), but collate according to LastName. Now your Name needs to understand the context it's in, and what you hoped would be a trivial semantic structure is anything but. All of this is to say: keep your data structures as simple as possible for as long as you can. Your future self will thank you.