Two cases showing imperfection of the const system

[SiegeLord]

On Friday, 17 February 2012 at 02:39:29 UTC, Andrei Alexandrescu 
wrote:
> That's a given. But that doesn't confer them infinite powers 
> otherwise inaccessible; you seem to require any flexibility 
> that seems reasonable within a context, and that's simply put 
> impossible. There is a point where inout's powers stop (inout 
> can be considered a special case designed for a few common 
> cases).

And can this not be a special case with a new type too? The issue 
is of moving the elements in an array while retaining the const 
correctness on the contents of the elements. Something like a 
rebindable reference to a constant memory?

> I think it's well worth trying this exercise. Given
>
> class Base {}
> class D1 : Base {}
> class D2 : Base {}
>
> define a non-template function that sorts Base[], D1[] and D2[] 
> without casts.

Naturally you can't, but that wasn't my point. My point was that 
I could do this:

sort(X)(X[] data) if (is(X : const(char)[]) && X.sizeof == 
(const(char)[]).sizeof)
{
      data[0][0] = 1;
}

This would compile just fine if you passed it a char[][]. Your 
templated function doesn't describe the semantics of the function 
(it shouldn't change the elements of the array, just their 
order). Is there a way around it? Is it better than casting?

> This calls for the obvious answer that there's a subset of D 
> that's usable without const.

Yes, but it doesn't have these bizzarities.

I like having const correctness in my code, I like the assurance 
that my memory isn't being mutated. Once I start using templates, 
it seems that that assurance can go out of the window sometimes 
because the template system is defined on the level of types, not 
on the level of const qualifiers.

-SiegeLord