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.
