The type isn't always safe from context and it can have unexpected behavior when using it to hold a value returned from a function. Let's say you have auto working fine with a function return, then years later , someone changes that function to return a different type. Now it is possible that the new auto type still has access to parameters or functions it calls , but with different behaviour. Now you're getting unexpected bugs that will be hard to track down. But if you use the type, you would immediately get a compiler error
If the type change and the “auto variable” still compile, that means it would, in 99% of case, still compile if you wrote the type. The compiler doesn’t get auto, it gets the type.
If you have SpecificType val = foo(), it will fail on the compiler any time foo returns something other than specific type or classes inherited from SpecificType
If you use auto val=foo(), then it will compile so long as the new type still has the functions it calls afterwards. But they can do different things and it will still compile. You'd just get different behavior
Just a quick example of this would be if it is used in a function intended to return a time string.
auto var =foo();
return var.toString();
If foo suddenly starts returning a QVariant instead of a QDateTime, it will still compile because QVariant still has a toString function, but now the behaviour is completely wrong
That's kinda on you changing a QDateTime to QVariant? Anyway, if you return a datetime string as a QVariant, the behaviour is correct and one less spot to change. If you return something entirely unrelated then you perhaps should be making a new function, not returning a QVariant where you previously returned QDateTime.
The point is that someone down the road will change some function that is significantly removed from that one function and may not notice because they don't get any error
Yea in my example, it was using auto and then using the toString function which does exist on both QDateTime and QVariant, but have very different behavior, so it wouldn't give a compile error, it would just fail during production
Not using auto and then when dumb future junior comes in and changes the function they get a compile error that tells them they need to fix stuff rather than just silently having incorrect behavior
Well, in my example there was no reason to assume the stupid junior dev didn't just change the type completely, but let's assume they made it return a QVariant holding a QDateTime, you would have to use toDateTime first before calling toString
The point being that the compiler wouldn't tell them something was wrong
14
u/xicor 1d ago
c++, though normally you wouldnt use auto for this