Generic programming ramifications of const by default

[Derek Parnell]

On Mon, 11 Jun 2007 12:11:40 -0700, Walter Bright wrote:

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


So how do we find out the answer to that?


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

... and that is a problem that no one can ever solve, right?
 
>> 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.

A problem with what? 

Are you concerned that it will confuse coders? Why? I have been coding
under that paradigm for years and your fear of problems is unfounded.
No-one coding in Euphoria has had a problem with the "inconsistancy" that 

   function foo(integer A)
      integer B

means that code calling foo() never has to worry about the parameter 'A'
being changed by foo() and that foo() can play with 'B' til its heart's
content.

This is not a concept that actually confuses coders. 

Is it a problem re metaprogramming with tuples as parameters lists? Why?
That is an obscure aspect of a little used technique. Are you sure that
there is no way on earth that anyone can solve this "inconsistancy"?

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell