5 ms·
So far, Go doesn't have warnings, which is great. Either it's an error, or it's nothing. This is great IMO, because I've seen too many codebases that just end
by dilap 10y ago
So far, Go doesn't have warnings, which is great. Either it's an error, or it's nothing.
This is great IMO, because I've seen too many codebases that just end up having infinite amounts of warnings that never get fixed, making them (1) useless and (2) annoying.
(Extraneous imports is a great example of something that in most languages would probably be a warning (or nothing); I remember in the early days people bitched like crazy about it, but on balance it's really really nice. (goimports also removed a lot of the pain.))
I think it's clear that if this goes in, people will use it beyond just refactoring. Honestly, I'm ok with that, if it's restricted to just types.
Here's something I've done from time to time:
func now() time.Time { return time.Now(); }
Just because typing time.Now() everywhere was getting tedious.
Having a type that's an explicit alias doesn't seem too bad to me.
type Time = time.Time
Sure, it's an extra step of indirection, but a very easy one.
(I feel like having variable aliases would be much more confusing, because variables are mutable.)
===
And it's not like the situation is that different from right now. For example, maybe I have some package with an api like:
func DateMagic(t time.Time) time.Time
OK, super-obvious what it's taking.
Now maybe I'm using aliases and you see:
func DateMagic(t Time) Time
Hmm, not quite as obvious, now you have to go lookup
type Time = time.Time
But still today I can do
func DateMagic(t x.Time) x.Time
Hmm what's x?
Oh
import x "time"
Of course it could get a little pathalogical...
func DateMagic(t DumbName) DumbName
type DumbName = time.Time
but I feel like you're really trying there.
- Jabbles 10y agoYou can use var now = time.Now
- dilap 10y agotrue, tho slight savings in characters not worth the less-clear definition imo
- skj 10y agoIs that really less clear?
- dilap 10y agoI think so -- if I see this it's obvious now is a function. func now() time.Time { return time.Now() } If I see this: var now = time.Time My first instinct is, "hmmm, some kind of variable?" And then I have to remember, "oh yeah, it's just a variable that holds a function." Obviously not a big deal either way. (I think this further shows how type aliases would not be adding much possibility for confusion compared to what already exists in the language.)
- ithkuil 10y agobtw if you want you can explicit mention the type in the var declaration
- randomdata 10y agoOn the other hand, you may want to set `now` to return a deterministic time value when testing, which the variable allows.
- blixt 10y agoI 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? :)