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.

Reply via email to