Generic programming ramifications of const by default

[Bill Baxter]

Georg Wrede wrote:
> BCS wrote:
>> Reply to Georg,
>>
>>> I think parameter passing is a world separate from "other const or
>>> const-as-default" areas. Thus, having parameters behave differently
>>> from them poses no risk for confusion, and, IMHO, is a conceptually
>>> clean and intuitive choice. It also has a crystal clear perimeter,
>>> which dramatically reduces the mental strain of having to remember
>>> things.
>>
>> The issue is that a and b in this code are of different types if T is 
>> a reference type and that same type otherwise.
>>
>> |void TFn(T)(T a)
>> |{
>> |  T b;
>> |}
> 
> (Disclaimer: I've been out of town some, so I might have missed 
> something important relating to this.)
> 
> Within the function (prototype or not), T a would be a read-only 
> variable and T b would be the correspoinding read/write variable.
> 
> Could you give me an example where this does pose a problem?

I think the big trouble here comes just from having const at all, not 
because of it being the default.

void TFn(T)(T a)
{
   T b;
}

If T is a reference type and you want a to be const, and b to not be 
const, then you've got some explaining to do either way.  But probably 
the most common case is that you want the parameter to be non-modifiable 
and the local variable to be modifiable.  And there const by default works.

There is a question about how to handle IFTI, which I believe the other 
const-by-default examples (Perl6 and Euphoria) probably don't have to 
deal with.   The question is should this:
     int x;
     TFn(&x);

deduce T as const-final-scope int* or just plain int*.  Regardless of 
the const-by-default issue, D will need a simple way to go back and 
forth between 'in T' and 'mutable T' so I think deciding that IFTI works 
either way would be fine.  But the IFTI issue definitely needs some more 
thinking.

--bb