Head Const

Ola Fosheim Grøstad via Digitalmars-d digitalmars-d at puremagic.com
Fri Feb 19 01:09:46 PST 2016


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.



More information about the Digitalmars-d mailing list