equivariant functions

[Gide Nwawudu]

On Tue, 14 Oct 2008 22:51:46 -0400, Benji Smith
<dlanguage at benjismith.net> wrote:

>Andrei Alexandrescu wrote:
>> Benji Smith wrote:
>>> I really don't see what all the fuss is about with the equivariance 
>>> stuff, except that it introduces a lot of confusing rules to fix the 
>>> holes in the (already complex and confusing) const system.
>> 
>> Please stop perpetuating misunderstanding and apprehension about the 
>> const system through statements strong on opinion and vague on detail. 
>> If you're willing to mention holes, complexity, and confusion about the 
>> const system, please explain where the holes are, where the complexities 
>> lie, and what aspects you are confused about. Suggestions for fixing 
>> said issues would also be welcome.
>
>Fair enough. Here are the reasons I describe the const system as "complex":
>
>* Comparable code without const qualifiers contains quantatitively fewer 
>semantic constructs than code that uses those qualifiers. Smaller 
>function prototypes are easier to read and comprehend:
>
>    char[] join(char[] str2, char[] str2) { ... }
>

But how would you know that the parameters are not modified? This
could lead to unnecessary dups in the client code. Personally, I think
it is easier to read a function signature, however complex, than to
read the function body.

The syntax is very important to the understanding of the concept, so
far I like the idea of 'const?' and the typedef{} idea, but maybe
reusing the keyword 'auto' could also work?

class S
{
     auto(this) clone();
     auto(this.field) getfield();
     int field;
}

Gide