Two cases showing imperfection of the const system

[SiegeLord]

On Thursday, 16 February 2012 at 23:14:54 UTC, Andrei 
Alexandrescu wrote:
> Hold them horses. I disagree. You're just saying it, but what's 
> your basis?

Because some cases (as shown below) trivially work within the 
const system, while some closely related ones don't. You're not 
going to be able to convince me of a demarcation that requires 
some const issues to require templates, and some not.

> This boils down to: "You want to sort an array of T[], U[], or 
> V[], where the three types are loosely-related, except U is a 
> supertype of both T and V and the three have the same layout. 
> What would be the signature of such a function?"
>
> The answer is (to a reasonable approximation) simple:
>
> sort(X)(X[] data) if (is(X : U) && X.sizeof == U.sizeof);
>
> This has nothing to do with qualifiers.

Because you removed them. While I agree with the type argument to 
a point, qualifiers have more meaning than just arbitrary type 
creation: they talk about mutability. The desired function 
signature states that the contents of the strings that are in the 
array will not be modified, your generic version does not have 
that stipulation. I can make up a body for that sort function 
which will work for types which fit your description, but fail 
for const(char)[], char[] and immutable(char)[].

>
>> Second case:
>>
>> inout was meant to solve issues with functions that return 
>> slices of
>> inputs. What about a class that is dedicated to the same 
>> functionality?
>>
>> E.g. this works fine:
>>
>> inout(char)[] half(inout(char)[]);
>>
>> But what about this:
>>
>> struct Slicer
>> {
>> char[] a;
>> char[] half();
>> }
>>
>> Note that the type of the input (the member 'a') must be the 
>> same as the
>> output of the half method. I don't know how to accomplish this 
>> without
>> templates.
>
> I don't know how to swim with a hand tied to my back, either. 
> The correct approach is to integrate templates in the 
> discussion and analyze _that_ context, not the artificial 
> context that precludes templates. D is not Go.

As much as you might prefer D to be 100% about templates, it is 
not, and there is a subset of it which is usable without them. 
This subset is the subject of this thread. There is no a priori 
reason why the first case should work and second should not 
within the confines of the const system.

> Associative arrays must be templates.

That's fine, but please try to compile this:

struct AAType(T)
{
   T[] Elems;
}

inout(char)[] test(inout(char)[] a)
{
    AAType!(inout(char)[]) b;
    return a;
}

-SiegeLord