Flimzy
2020-11-29 00:55:36
I hesitate to answer, because this is ultimately an opinionated question. But the reasons I would avoid this are:
- It's very non-obvious, and thus arguably violates the Principle of Least Astonishment. If I ran across that in some Go code, I would think it was a mistake, or cruft from a migration, and I would try to remove it.
- Even at face value, the documentation value is dubiuos, at best. It should be pretty clear from context that
map[string]Usershould map usernames to users. If you have multiple similar maps, one which maps usernames, one which maps userids, for example, the name of the variable should disambiguate. If it doesn't, a type alias probably won't be sufficient either. You'll need some clear documentation. - And finally, static analysis tools, such as those built into many IDEs, will resolve a type alias to it's canonical type, which means that any perceived documentation value will be limited anyway.
would you say the same for a regular def
type Username string?@mh-cbon: Not all of the points apply to a stabdard type definition. Which one are you asking about? Generally, though, I prefer to reserve type definitions for functionality, not documentation. I find constantly type converting back and forth between a named type and a base type to be cumbersome, and prefer to avoid it except when I have functionality built into a type.
I find constantly type converting back and forth between a named type and a base type to be cumbersome, and prefer to avoid it except when I have functionality built into a type.this is a good reason i agree with. I raised the point in case OP is confused about the various type definitions.the concern about converting between a named type and base type isn't applicable to type aliases because type aliases don't actually create a type, so plain string's would work in my example, correct? this was actually one benefit I perceived from using type aliases.
@user2133814: Right, conversion is NOT applicable to aliases.