So it seems 'const' has gone the way of 'register' - ignored by the compiler.

Just the optimizer. The compiler still enforces it as it reads the code.

I'd guess that the optimizer can't really count on it because it could get aliased by code the optimizer can't see and then casted away.

Yeah. const_cast (and C-style casts) and mutable existing in the language make const pretty useless to the optimizer. But at least they are trying to get some benefit from it in some cases. A C++ variant (compiler flag) that would remove const_cast, mutable and the cast-const-away parts of C-style casts from the language and allow the optimizer to put more value into 'const' could be interresting.

ISO Core C++ is trying to do something like this. They have to, in order to count on the properties of "const" for their static safety analysis.

(I have my reservations about whether ISO Core C++ with the lifetime profile really qualifies as C++ anymore due the massively backwards incompatible nature of the changes, but it'll be interesting nonetheless.)

Can you link to more information about this? Googling for "c++ core lifetime profile" just takes me to the Core Guidelines.

Is the idea that they'll codify a bunch of static analysis that disallows problematic constructs & patterns? Could implementers then add something like Rust's ownership checks (assuming full source visibility)?

My sibling commentators have given you good links, but it's worth noting that these systems and Rust have a lot of differences. For example, they're explicitly not trying to tackle data races, and the way that they work is different.

I'm excited to see this all play out though!

CppCon 2015: Herb Sutter "Writing Good C++14... By Default":

https://youtu.be/hEx5DNLWGgA

Sutter comments on const_cast around 11m15s.

Yes.

Microsoft has delivered a beta version of it with VS 2015 Update 1.

Clang guys are improving clang-tidy for similar errors.

Check Herb Sutter's talk at CppCon 2015.

const_cast<> isn't the root of the problem. If someone passes you a pointer to a const pointer to a non-const thing, they can still just mutate the non-const thing without any casts. You'd have to forbid non-const to const pointer conversions entirely (which would imply removing const_cast<>, as there would no longer be any situations in which it was legal to use).

Right. There are lots of corner cases that would need to be identified and considered in the case of a "strong const" C++ variant (like what you point out) - I still think it could be an interresting experiment.

What's the problem with the "mutable"? I thought that it does not impair the type safety.

You can't assume the object is not modified by a const member function if the class has mutable members.

Would that mean not being able to use const in unions?

I've never actually seen a union used in a C++ codebase. What's the usecase? I know people use them in C for bitfields, but outside of embedded (which is almost always just pure C) that just doesn't seem to come up

Embedded can be almost anything, C/C++/java and so on. I've seen microcontrollers with 8K of program space, written in C++. Why? Because it optimizes better than the 'C' programmer does.

Unions are used for interpreting any kind of record stream. Reading serialized binary objects from a file? Use a union. Network packets? A union.

When reading from a binary source, I've seen that, instead of unions, the char pointer will be cast to a pointer to the appropriate data structure. What is the advantage of using a union instead of casting?

Well, for one, unions have defined behavior in C, while passing pointers around and casting them randomly doesn't.

I don't know if this is the best example. Generally you see unions in C to cover "tagged unions", I.e. Those things that would be subsumed by algebraic data types in other languages.

Ah, got it. I am used to C++, where accessing the non-active member of the union is undefined behavior. Thank you.

The usual way to do this via memcpy, rather than either a union (requires some non-portable extension like "packed") or pointer casting (invokes undefined behavior if alignment isn't satisfied).

Here's one use of union in a C++ code base (sf::Event): http://www.sfml-dev.org/documentation/2.3.2/classsf_1_1Event...

Tagged pointers - hiding a few bytes in a pointer address.

Tagged unions are often used as substitute for the missing std::variant

Tagged unions are often used in C to provide a form of Sum Type.

Which, to be fair, is all register buys you also: the compiler isn't supposed to allow you to take the address of a register variable (although the Plan 9 compiler didn't enforce the rule).

Well, they are actually trying to extract some meaning from it for optimization purposes, so I wouldn't call it 'ignored'.

'inline' would be a better example of another "ignored" keyword.

What useful meaning is there for optimization purpuses?

As far as I know, there is no meaning in pointer-to-const other than it must not be used directly to modify the stored value (if it is you get a compile error). It is always valid from the perspective of language semantics to cast-away the const and modify the pointed-to object, as long as the object is not itself read-only. So, to my knowledge, they could not make any additional assumptions based on pointer-to-const, though they could use it as a hint to look for a possible optimization.

Did you read the link? It's all explained there.