equivariant functions

[Bruno Medeiros]

Benji Smith wrote:
> 
> * 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) { ... }
> 
>    const(char)[] join(const(char)[] str1, const(char)[] str1) { ... }
> 

Together with the existing 'string', I've created aliases of my own: 
'mstring', short for mutable string, same as 'char[]', and 'cstring' for 
const string, same as 'const(char)[]';
I've found they bring not only less typing, but also less mental 
workload (like, easier to read).

   cstring join(cstring str1, cstring str1) { ... }

Although that's mostly because of the fact that I don't have to 
immediately think of them as arrays of characters.

> 
> * The idea that "const" is a supertype of "mutable" and "invariant" is 
> utterly bizarre to me, since it violates the "is a" rule of type 
> hierarchies. I understand that, for the sake of overloading, both 
> "mutable" and "invariant"  can be implicitly cast to "const", but the 
> other implications of that relationship are beyond my grasp at the moment.
> 

Like Andrei said, it does not violate the "is a" rule of type hierarchies.
An invariant type can be used as a const type without breaking any of 
the contracts of invariant. Thus, it's a subtype as per the Liskov 
substitution principle. (and the same with mutable)


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D