Proposal for scoped const contracts

[Steven Schveighoffer]

"Walter Bright" wrote
> Steven Schveighoffer wrote:
>> It is basically an idea for scoped const.  The main goal is so that one 
>> can specify that a function does not modify an argument without affecting 
>> the constness of the input.
>
> I understand what you're asking for, and it does solve some issues. It's 
> almost exactly the same as the "return" qualifier I'd bandied about last 
> summer:
>
> T foo(return T t);
>
> where the 'constness' of the argument for t is transmitted to foo's return 
> type at the point of call of foo(), not at the point of definition of foo. 
> This implies, of course, that foo cannot change t itself.

This is sort of a subset of what I am proposing, as for my solution, the 
return type may be not just of type T, but must be of the same constness. 
This is important if you have a function that returns a member of a struct 
or class, that you want to carry the same constness factor (think 
properties).

>
> For me, the question is is solving these issues a large enough problem 
> that justifies adding a rather confusing new variation on const?

To me, many functions that would be a good candidate for const are now 
removed from being fully-const.  I have mentioned in my post strstr, and 
min/max.  There are a whole slew of functions that would benefit, but must 
now be either re-implemented for each version of const, or cannot be 
implemented with const at all.  Think of properties.  Only one function is 
required for const, invariant, and mutable.  Think of text processing, only 
one function for all these constancies, plus the mutable versions can return 
mutable values while promising that the function is const.  Without this, 
string processing functions that take 2 arguments would generate potentially 
3^2 x 3 = 18 variations, the 3^2 being const invariant and mutable for each 
argument independently, and the x 3 factor for char, wchar, and dchar.  With 
this change, only 3 functions for char, wchar, and dchar. This can also have 
optimization and functional programming benefits.

As for being confusing, I don't see it to be any more confusing than const 
or mixin was to me to begin with.  Like any feature that does not have a 
precedent, this will take some learning, but the resulting code will be so 
much more maintainable, readable, and functional.  I am biased of course, 
since I proposed the idea :)  But I know of at least one other person that 
thinks this is needed.

Couple that with the fact that the 'in' parameter syntax already exists! 
Just add the 'out' for the return value, and allow 'in' variables.  IMO, 
'in' and 'out' are very understandable, already used words in programming to 
mean 'input only' and 'output only'.  Well, I guess 'out' in this context 
doesn't really mean that, but it is necessary to have a keyword to show how 
const would apply to the output type in case it doesn't match the input 
type.  Like I said in my original post, any keyword is fine with me as long 
as the functionality is there.

If at the end of having const permeated throughout the language, nobody uses 
it because it's too unwieldly, then it's not a good feature, no matter how 
many theoretical problems it solves in special case programming.

-Steve