[Qt-creator] Using C++11 in Creator's source

[André Pönitz]

On Wed, Mar 05, 2014 at 12:20:13PM -0800, Jonathan S. Shapiro wrote:
> Because auto actually isn't type inference, it turns out to be less useful for
> local declarations than it might initially appear.
> 
> Personally, I think that type names as documentation for locals have limited
> value.

I disagree, unless by "limited" you mean "to a large degree, but not
necessarily full".

There's a concept of "True Name", mythological or not. People tend to think
in terms of "Cow" and "Earth" and "Cat" and "Tree", not in terms of "X1",
"X2", "X3", "X4", let alone it terms of "Something somedeeds something".
Of course, this requires a certain culture that allows to rename things, or
invent new names if meanings change or new concepts appear. Not all code
bases are that flexible, for various reason, but especially for the Qt
Creator code base I am ready to claim that the barrier to call things by
something close to their "True Name" (read "without arbitrary political
restrictions") are rather low.

> If you don't know what NewMenu() returns, you shouldn't be calling it in
> any case.

The normal situation is that I am _not_ _writing_ that code, but I am
_reading_, or rather 'browsing' it, usually in the process of hunting down
a bug, i.e. in a context where "something is likely to be wrong". I might
be roughly familiar with the code base as a whole, but I usually have not
seen a particular line before (or forgotten about it, which amounts to the
same)

_Even_ if the rule was "'auto' means 'I believe type does not really matter
here'" it would hurt in that case, as it removes otherwise 'provably
correct' information ("type is X, as it says X, and compilers are happy")
from sight.

Having "enough" "reliable" context information definitely helps as stepping
stones.  That's where properly naming types and objects (and renaming
things if meaning changes) comes into play. 

Of course, one could "legally" within the language call types x472132,
x472332, ...  and instances x472232, x472432, ... and it wouldn't change
the formal correctness of the code.

Would it affect readability and maintainance?  - I am ready to bet on "yes".

> Dropping the explicit types has a significant advantage when new code
> is being written, because it reduces the amount of type name changes you are
> forced to make. All of this is especially true for temporary variables that go
> out of use after only a few lines.

Code is more often read than written, and usually not by the people who
wrote it.
 
> I have no general conclusions or even recommendations - this is something where
> the community needs to decide on a working fit. What I *do* suggest is that
> some experimenting is in order to see what feels natural after a bit of
> experience.

Some experimenting is definitely fine. I am "only" proposing to start on
the cautious side. I think so far nobody was opposing the "iterator case",
or even the "duplicated within a line" rule. That would be a start.

Andre'