Two cases showing imperfection of the const system

Timon Gehr timon.gehr at gmx.ch
Fri Feb 17 05:52:49 PST 2012


On 02/17/2012 06:54 AM, SiegeLord wrote:
> 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?
>

As I suggested in my other post, use inout(void) sort(inout(char)[][]) 
for the semantics you want.

>> 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

Template functions cannot violate const correctness any more than normal 
functions can.





More information about the Digitalmars-d mailing list