Interesting way of elevating bug issue to compile time. I'll definitely try to apply it to my TypeScript Front-End.
I use the newtype pattern a lot in Rust. I try to avoid passing strings around. Extracting information over and over is cumbersome. Ensuring behavior is the same is big-ridden.
An example: is a string in the email address format? Parse it to an Email struct which is just a wrapper over String.
On top of that we then assign behavior to the type, like case insensitive equality. Our business requires [email protected] to be the same as [email protected]. This way we avoid the developer having to remember to do the checks manually every time. It's just baked into the equality of the type.
But in Rust using
type Email = String;
just creates an alias. You really have to do something like
struct Email(String)
Also, I know the only way to test an email address is to send an email and see if the user clicks a link. I reply should introduce a trait and a ValidatedEmail and a NotValidatedEmail.
I use the newtype pattern a lot in Rust. I try to avoid passing strings around. Extracting information over and over is cumbersome. Ensuring behavior is the same is big-ridden.
An example: is a string in the email address format? Parse it to an Email struct which is just a wrapper over String.
On top of that we then assign behavior to the type, like case insensitive equality. Our business requires [email protected] to be the same as [email protected]. This way we avoid the developer having to remember to do the checks manually every time. It's just baked into the equality of the type.
But in Rust using
just creates an alias. You really have to do something like Also, I know the only way to test an email address is to send an email and see if the user clicks a link. I reply should introduce a trait and a ValidatedEmail and a NotValidatedEmail.