2 ms·
I don't think realiasing exported signatures is a good idea, in any language. However, doing what you do in your package as a private function is perfectly fine
by blixt 10y ago
I don't think realiasing exported signatures is a good idea, in any language. However, doing what you do in your package as a private function is perfectly fine, that is for your own convenience.
Regardless, I don't think the argument that the Go maintainers are making is that this is about number of characters saved. The point of an alias in the first place is to make it more feasible to carry out breaking API changes (which are an important part of any maturing API).
So if aliases are introduced for the purposes of making API transitions possible over multiple commits, then I think they should be clearly designed as such. Which means that it shouldn't tempt people to do what you just described in your comment. Maybe that wouldn't be a bad thing, but if that becomes the ultimate use for the aliases, that use case should play a bigger role in the design of aliases.
Because right now, as far as I can tell, they're being designed mainly for API transitions.
- dilap 10y agoWell, I could easily have made it "func Now" or whatever in my current package. The point is, adding type alias just gives you the ability to do for types what you can already do for variables and functions. It's true that the driving case (as presented by rsc) is co-reorganizations, but I think inevitably it'll get used for more than that. (Which is what many people who are opposed are afraid of.) I would not personally be a fan of making the feature so deliberately painful to "discourage" use. Either add it and make it as nice as you can, or don't. Why add ugly things to your language on purpose? :)