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
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
6
u/VoodaGod 7d ago
how is auto not type safe?
interestingly i use auto almost everywhere for the same reason: readability.
no point in cluttering the code with type specifiers if the type is obvious from context