const?? When and why? This is ugly!

Burton Radons burton.radons at gmail.com
Fri Mar 6 11:39:03 PST 2009


Walter Bright Wrote:

> Burton Radons wrote:
> > I don't get it either. Any possible application for const in the form
> > of code correctness went out the window once the invariant virus
> > forced all strings to be invariant whether they were or not; so I
> > still need to use dup to guarantee that data won't change underneath
> > me, but then I need to cast it!
> 
> My experience is that when dup is used to guarantee that the data won't 
> change underneath the problem is being addressed at the wrong end. The 
> mutator of the data dups it, not the user.

I don't know the origin of the string or where it's going. I only know it's "invariant (char) []" now, because you're required to have it "invariant (char) []" because of the viral nature of const and that's how the string is defined, so that's what my API takes. It certainly doesn't mean that anyone is intentionally using the API incorrectly; everything takes "invariant (char) []", so my function doesn't deserve special treatment without stating so.

A more accurate way would be for the string type to be "const (char) []", and for functions which retain strings that can't change to take "invariant (char) []". That makes pretty good claims about the nature of the string, but it would clearly result in lots of cast management.

I think all these problems boil down to the fact that invariant tells you about the container rather than the object itself; but whether the object actually is invariant is totally independent of the container. The genius of D 1.0's const is that it makes an actual, actionable true statement about the object. That was a HUGE benefit. This tries to push it back into C territory and I don't think it works.

I don't buy that this is going to lead to any MP bonuses either. Const has turned into a form of the sufficiently complex compiler fallacy, the cure for any ail. But if you can cast const on or off, then any declaration you make about the mutability of the data is going to be wrong at some point, and compilers can't sometimes build the right code.

> > It doesn't affect pure at all,
> > because pure can be passed invariants which are just casted - the
> > compiler needs to use rules which are a hell of a lot more binding
> > than anything we can provide it to make these determinations. Now
> > that const is not a storage class, it's actually not possible to
> > declare function variables which should be stored in read-only memory
> > (unless if it's encoded somewhere in the thirty or so combinations
> > you can use), which also damages pure. It's a lot more confusing to
> > deal with const data altogether than it used to be.
> > 
> > When I switched from D 1.0 to 2.0 I tried several times to port some
> > large pieces of code over and ultimately gave up, just as everyone
> > has given up trying to do it in C++. It's a hard task moving code
> > through that kind of change.
> > 
> > I've learned to handle it but I would really like to not be fighting
> > the compiler all the time. Is that what I'm supposed to be doing
> > here, really?
> 
> Can you be more specific about what was stimying you, as perhaps we can 
> think of a solution.

Exactly the same thing as trying to do it in C++. You're stuck iteratively applying const to pretty much everything, and applying tons of casts to get the compiler to shut up. D does provide the mechanisms to have proper safe mutableCast/constCast/invariantCast functions (well, safe except that they make it so that neither compiler nor programmer can make any good statements about the nature of the data), but when trying to shift code around you usually just want to make it work.

I remember that one thing that really got to me was that you had a foreach term as invariant at that point if it weren't defined as inout. The thing is, that was correct and could've led you to a sweet easy compiler optimisation, but it's like const is in this balance where properly implemented it would be brutal and ugly, so we need to back everything off until it's only at an acceptable level of annoyance.

Oh, and templates. Templates that have nothing to do with any of these matters keep on having to be changed to appease the const god. Dealing with templates when you're doing really crazy stuff's bad enough without having that around.



More information about the Digitalmars-d mailing list