Generic programming ramifications of const by default

[Don Clugston]

Walter Bright wrote:
> Bill Baxter wrote:
>> Walter Bright wrote:
>>> Bill Baxter wrote:
>>>> * "having same type defaults is better for generics"
>>>>   (maybe...but I'm not convinced. If you have powerful enough 
>>>> metaprogramming it shouldn't be hard to strip const from a type 
>>>> tuple, or add it.  And people do far more programming than 
>>>> meta-programming.)
>>>
>>> This is a good point. With const-by-default, you have function type 
>>> declarations behaving *fundamentally* different from other 
>>> declarations. Given the metaprogramming ability to use tuples to 
>>> declare parameters, doing function template type deduction for 
>>> parameters, and type inference on parameters, making this 
>>> fundamentally different may wind up really screwing things up.
>>
>> Yes, it's a good point (it's David Held's point), but again your 
>> argument is "may wind up really screwing things up".  On the other 
>> hand it may wind up *not* screwing things up.  Gut feelings are great, 
>> but neither you nor David have given any concrete examples.
> 
> The problem is that metaprogramming is in its infancy. I don't know a 
> case that will screw up, but there's not a lot of metaprogramming out 
> there. Any sort of glaring inconsistency in how declarations work is a 
> potential future train wreck.
> 
> It reminds me a bit of how people argued that using < > for template 
> arguments would be fine, it was just a minor inconsistency. It wasn't, 
> as the inconsistency threw wrench after wrench into the gears of later 
> ideas, and eventually forced several wacky syntactical workarounds.

That's true, but I'm not convinced that this is analogy is appropriate. There is 
a symmetry between 'const by default' and 'mutable by default'.
C++ style const is a disaster for metaprogramming. Avoiding 'const-by-default' 
is no guarantee that trains stay on the rails.

Secondly, it seems to me that CTFE will supplant the overwhelming majority of 
uses of template metaprogramming, especially when macros come along.

If there is a merger between compile-time and run-time reflection
(eg, unified syntax between static if(is(xxx)) and if(typeinfo(xxx)), allowing 
is() expressions inside CTFE functions, even more uses of templates would drop out.

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

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

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