On Friday, 19 February 2016 at 08:51:26 UTC, Shachar Shemesh
wrote:
The way I see it, here's how it is with C++:
Get const pointer. Cast away its constness. If the original
data was mutable, you're gold. If not, undefined behaviour.
Yes, and since interpret_cast<> seems to not accept casting away
const, you have to use const_cast<>, so const_cast<> and mutable
are at least explicit.
I fail to see how the C++ way is any worse than ours.
The focus in C++ seems to be to add semantic analysis of
correctness as a separate stage from compilation. No reason for
why you cannot have both strict constness and lifetime analysis
in an individual C++ project. C++ seems to be increasingly a
platform for "your chosen semantics" rather than a single
language.
But const is still problematic in C++ as well. Mostly thanks to
generic programming where types can have a completely different
implementation if the parameter is const or mutable.
So I am not sure if const should be part of the regular type, but
more along the lines of behavioural typing / type state / deduced
quality / constraint.
Current languages sacrifice way too much for separate compilation
and crude header files/attribute files. They could save both
code-gen IR + semantic analysis IR instead, and feed that to
various tools.
