daviddenton
commented
1 year ago I quite like this idea. As for the invalid values, I think that rejecting them is a fair default. For custom cases (such as the MAC address) I'd tend to do a custom type with more targeted behaviour. Maybe we can try to modularise the aspects separately so you can compose custom types out of those behaviours? 🤔
Any interest in adding value classes for common bases, i.e. 16, 32, 36, 64? They have applications not only in encoding binary, but also for setting easily understood constraints on identifiers. All of these values can be built with the existing tools, but it might be nice to have additional shortcuts.
However, there's no single proper way to handle out-of-bound characters; rather than reject the entire string, the developer may choose to have the invalid characters stripped, or coerced (in some cases). Making a single decision on which strategy to use might disqualify the value for many use-cases, but supporting multiple cases with options may be more than we want to handle in this library. Thoughts?
Example: For a base16/36 value, the developer may choose to coerce to uppercase Example: For a MAC address, the developer may choose to strip the colon separators to coerce it to base16