It might be easier to change types behind the scenes when using auto, but why would someone feel that is going to be a common case? When are you completely changing types all the time?
More often, the types don’t change all that much, but their behaviors get extended and new features have to be calculated in some block of code. If you can see the type explicitly, then you know what operations it supports, etc.
If I come across a structured binding where x and y are auto assigned as the unpacking of struct fields whose types might be complicated, now I have local variables x and y that I cannot reason about until I backtrack manually to figure out what type they will be deduced to having (and then keep that in memory any time I’m tinkering in that section of code).
I guess for the cases when big structural overhauls are happening behind the scenes to radically change underlying types and designs, auto would reduce a bunch of rework on type annotations. However, I just can’t believe anyone would allow that to be a common enough use case for it to matter more than explicit type annotations.
More often, the types don’t change all that much, but their behaviors get extended and new features have to be calculated in some block of code. If you can see the type explicitly, then you know what operations it supports, etc.
If I come across a structured binding where x and y are auto assigned as the unpacking of struct fields whose types might be complicated, now I have local variables x and y that I cannot reason about until I backtrack manually to figure out what type they will be deduced to having (and then keep that in memory any time I’m tinkering in that section of code).
I guess for the cases when big structural overhauls are happening behind the scenes to radically change underlying types and designs, auto would reduce a bunch of rework on type annotations. However, I just can’t believe anyone would allow that to be a common enough use case for it to matter more than explicit type annotations.