constancy and template parameters in D2.009+

[Janice Caron]

On 12/13/07, guslay <guslay at gmail.com> wrote:
> but a.method() and const a.method() are not the same method call!

No one said it was. You're confusing a function call with a template
instantiation. Be careful - that's a very different thing.

What we're talking about here is the difference between A!(int) and
A!(const(int)). In D2.007 they were distinct by default. Walter says
that led to a lot of instantiation bloat, so in D2.008 they were
coalesced by default.

Consider a function such as:

    T max(T)(T x, T y) { return (x > y) ? x : y; }

Do you /really/ need separate instantiations for T==int and
T==const(int)? Of course not. Walter's choice is reasonable. (It may
not be perfect, but it's reasonable).


> This is apart from the side effect that you lose const protection.

No you don't. If const correctness is ever violated, it's still a compile error.


> Regarding coexistent multiple specializations, assuming they are all the same, i would like to know exactly in what respect this is detrimental.

<shrugs!> That's Walter's decision.



> Also, how often does one instantiate all flavors (there are three) of const qualifications in an application?

I would say rarely. Certainly there are cases when it's important -
Array!(int) and Array!(const(int)) need be distinct, for example, so
that they can behave like int[] and const(int)[] respectively, but
apart from collections, the distinction is probably wasted.



> > But sometimes it matters, which is why Walter allowed the (T:T)
> > notation, for when it does. I just think there has to be a better
> > syntax for that!
>
> I am all for a mecanism to discard const-qualification in the definition of the interface (as opposed to casting away const from the call site everywhere) if there are benefits. I just hardly see how this should be the default.

I honestly don't care - so long as I get the best of both worlds, and
a sufficiently non-confusing syntax.