Okay, what happened to my literal strings?

[Robert Fraser]

Burton Radons Wrote:

> Ah, so 'const char [] foo = "bar";' works, does it? No thank you. Const 
> forcing (whatever the name given) is the kind of tiddlywinks 
> obsessive-compulsive bullshit that can't even be enforced so it's useless to 
> everybody* which caused me to flee from C++. I've been using D as my primary 
> language for... five years and four months now, and this lack has not 
> resulted in a bug once. Needless to say, C++'s const didn't save me from a 
> single bug either, but instead wasted my time (just like a bug does - the 
> irony of many mollycoddling features is that they cause you to spend more 
> time dealing with them than you would to deal with the bugs, if they even 
> existed) by having me pour over code inserting const or casts everywhere 
> like the virus it is.
> 
> This is _significantly_ against what I want from a language, and while I'm 
> not sure how I'll feel in a day or two, my current inclination is to move on 
> to another language or write my own. The many megabytes of code to retrofit 
> don't help either.
> 
> * Some might be deluded into thinking it's useful to them for optimisation, 
> bug prevention, or interface contracts. But the only thing circumventable 
> const forcing does with any faculty is provide self-documentation, and even 
> there the signal-to-noise ratio is pretty awful, it's easily abused (methods 
> are frequently declared const in C++ when it's not a true requirement of 
> what the method does, and it prevents situations where the method really is 
> const but also modifies the object's data, which is not a paradox - the data 
> might be cached or synthesized), often fraudulent, and usually not 
> enforceable by the method. This is well-discussed and it seemed to be how 
> Walter felt originally, so if someone can point out anything specific which 
> changed his mind I'd be interested in seeing it. 
> 

As Reiner pointed out, modifying literal strings can lead to hard-to-find segfaults on Linux. It took me about an hour to find this the first time it happened to me when I started programming in C. I haven't made the mistake since, but still...

For what its worth, I don't like const enforcing either, I think it's generally a waste of time. But it's very good, IMO, for one thing, and that thing is multi-threading. Knowing a value is invariant (and making sure the compiler knows it, too) means you don't have to lock it. For single-threaded programs, I would never write a "const". But locking/synchronization is slow, and if you're working on a big project (i.e. you're not familiar with thole codebase), it's always good to play it safe with shared class references. Knowing that the class reference is _invariant_ (not const as in C++ const, since there may be mutable references) means you don't need to lock it, increasing performance and making code easier to write.

Walter said this about C++'s const, which displays many of the pathological problems you describe. D's const _is_ enforceable (well, const isn't, since it can be cast away, but invariant is, because invariant data can be placed into ROM).