const debacle

[Janice Caron]

On 26/03/2008, Steven Schveighoffer <schveiguy at yahoo.com> wrote:
> "Janice Caron" wrote
>
>  Your way of explaining how the resolution of inout works as 3 separate
>  function bindings is good for understanding purposes.  I'd amend my rules to
>  be similar:

I've just figured out an /even easier/ way of describing this. I've
got it down to just two rules now.

Rule 1: inout(T) is a typedef for const(T)

This automatically implies that inout(T) is a distinct type from
const(T), that nothing can implicitly cast to inout(T), and that
inout(T) will implicitly cast to const(T).

Rule 2: When a function declaration is compiled, in which at least one
of the function parameters (including this) contains an inout(T) type,
three additional functions are generated by the compiler, which apply
casts to parameters and return type as appropriate.

e.g. If you write

    inout(T) f(inout(T) x, inout(T) y)
    {
        whatever;
    }

then the compiler adds

    T f(T x, T y)
    {
        return cast(T) f(cast(inout)T)x, cast(inout)T)y);
    }

    const(T) f(const(T) x, const(T) y)
    {
        return cast(const(T)) f(cast(inout)T)x, cast(inout)T)y);
    }

    invariant(T) f(invariant(T) x, invariant(T) y)
    {
        return cast(invariant(T)) f(cast(inout)T)x, cast(inout)T)y);
    }

Those are the /only/ rules you need, because the existing function
signature matching algorithm will always pick the right function, and
the extra three functions will all be inlined so there's no code
bloat.

I like keeping the explanations simple! :-)