Two cases showing imperfection of the const system

[Andrei Alexandrescu]

On 2/16/12 6:49 PM, SiegeLord wrote:
> 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.

Some cases also work trivially with subtyping, while some closely 
related ones don't.

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

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

I should confess that the subtyping relation (const(T) is a supertype of 
both T and immutable(T)) has from day 1 been a guiding design principle 
for us, so that shouldn't be taken lightly. There is a relation between 
types that is somewhere in between simple subtyping and qualified types: 
subtype with layout conservation, i.e. you know that T is a supertype of 
U and both T and U have identical layout. For such types we could 
accommodate special capabilities in the type system; they'd be 
applicable beyond qualified types.

> 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)[].

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.

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

(let's stay on topic and not make this ad hominem, thanks)

> it is not, and
> there is a subset of it which is usable without them.

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

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

I understand your complaint, but I don't know how to design a type 
system that is at the same time reasonably small and simple and allows 
all of your examples and some related ones. We have "inout" which is 
helpful but at the end of the day a special case for a category of 
situations. We can't expect it to do miracles.


Andrei