Const correctness revisited (proposal)

[Janice Caron]

On 24/03/2008, Oliver Dathe <o.dathe at gmx.de> wrote:
>  That's right what pushed me to think about tail constness regarding
>  parameters. You could have the cont-ness contract without touching the type.

Just to be pedantic, the word is "constancy", not "const-ness". :-)

>    T[] f(T[] t const) {
>      return t;
>    }

What if I wanted to distinguish between const(T)[] and const(T[])?
What if I wanted the type of t to be "const(T[])[]"? Declaring "T[][]
const" doesn't show where the brackets are supposed to go.
Const-at-the-end doesn't make sufficient distinction.

Furthermore, as I'm sure Walter will point out if he replies to this
before I do, "transient constancy" will break const correctness, and
so /must not be allowed/, whatever the syntax.

Not that I want this, but if you really wanted to allow slices to be
returned, a better way would be something like

    sliceof(t) f(const(T)[] t)
    {
        return t;
    }

This would not introduce any new kinds of constancy, however, the
compiler would now have to /prove/ that the return value was
guaranteed always to be a slice of t, and generate a compile error if
not. Proving that might be non-trivial!

So, even though I believe that returning such a slice is not quite so
unsound as Walter believes, I nonetheless argue that doing so would be
too complicated to implement, and therefore should not be implemented.
You don't need it, because you can just return indeces instead, and
then take the slice at the call site. Returning indeces is the easy
way, and seems sufficient to me.