Generic programming ramifications of const by default

[Walter Bright]

Don Clugston wrote:
> If const-by-default is OK for normal functions (including CTFE), I find 
> it hard to believe it would be particularly problematic for 
> metaprogramming.

We just don't know.

> I can see so many benefits for const-by-default, and it is far more 
> intuitive (when I originally read the descriptions of 'in', 'out', 
> 'inout' in the spec, I thought that D uses const-by-default!) -- so I 
> think we really need to be certain that const-by-default is not possible.
> 
> I keep thinking of examples like:
> 
> struct A {
>   B b;
>   C c;
> }
> 
> and wanting to create an opCall-style constructor.
> I want to create a function of the form
> 
> A func(A.tupleof params);
> 
> In the normal case, I don't want to modify any of the parameters. So 
> they should all be const. With mutable-by-default, it's necessary to add 
> 'const' to all of the tuple elements; it definitely adds _some_ 
> complication to the most common case for metaprogramming.

I think you should be able to do:
   A func(in A.tupleof params);


> The argument 
> seems to be that const-by-default would make the less common 
> metaprogramming case unbearably horrible. I'd like some evidence for 
> this. At least a hint that it's worse than mutable-by-default.

It's not that it's worse, it's that there's an inconsistency. Having a 
type mean one thing as a parameter and quite another as a local is 
probably going to be a problem.

> In the absence of any evidence against it, my vote lies strongly with 
> const-by-default.