> But to force these beliefs on others through laws is crossing a line you will regret at some point in your life.
Where did they argue for a policy solution?
Where did they argue for a policy solution?
type AccountName string
except you write it like (abridged) type AccountName refined.Scalar[AccountName, string]
func (AccountName) IsValid(value string) bool {
return accountNameRegexp.MatchString(value)
}
and that enforces an invariant through the type system. In this case, any instance of type AccountName needs to hold a string conforming to a certain regular expression. (Another classical example would be "type DiceRoll int" that is restricted to values 1..6.) var name AccountName // initialized to zero value, i.e. empty string
and now you have an illegal instance floating around (assuming for the sake of argument that the empty string is not a legal account name). You can only really guard against that at runtime, by panic()ing on access to a zero-valued AccountName. Arguably, this could be guarded against with test coverage, but the more insidious variant is type AccountInfo struct {
ID int64 `json:"id"`
Name AccountName `json:"name"`
}
When you json.Unmarshal() into that, and the payload does not contain any mention of the "name" field, then AccountName is zero-valued and does not have any chance of noticing. The only at least somewhat feasible solution that I could see was to have a library function that goes over freshly unmarshaled payloads and looks for any zero-valued instances of any refined.Scalar type. But that gets ugly real quick [1], and once again, it requires the developer to remember to do this.
https://xyrillian.de (podcasts and blog) https://github.com/majewsky Mastodon: https://digitalcourage.social/@xyrill
What I say is often colored by my work experience, but opinions are always my own and not those of my employer.