const debacle

[Janice Caron]

On 24/03/2008, Jarrod <qwerty at ytre.wq> wrote:
>  I know everyone is throwing in some kind of template or overload idea,
>  but mine is a little more simple: Change 'in'. Use 'in' to define a
>  function that will take a value and not change it, but make no guarantees
>  about the return type

I'm going to have to join forces with Walter on this one. It doesn't
matter what syntax you use to declare function parameters - any such
declaration, whatever the syntax, /will break const correctness/.

What if I declare

    T[] f(in T[] a, const(T)[] b)
    {
        auto c = someTest ? a : b;
        // what type is c?

        return c;
        // can we return c?
    }

It's just too messy. If you really, really, really want to do this,
you want the special tag to be on the return type, not on one of the
input parameters. After all, what would

    T[] f(in T[] a, in T[] b)

mean, in your scheme? Does it mean we can return either a slice of a
or a slice of b? I don't believe that that is in any way desirable.

The only way that I can think of doing it would be to tag the return
type, with something like:

    sliceof(a) f(const(T)[] a, const(T)[] b);

or

    sliceof(b) f(const(T)[] a, const(T)[] b);

That way, the compiler would know which input was allowed to be sliced
- and /there can be only one!/

More to the point, the compiler would have to /prove/ that the return
value was, in all cases, a slice of the declared variable, so that it
could emit a compile error if it wasn't. I don't know much about
implementing compilers, but it seems to me that this would be a very,
very hard thing to prove.

The simpler solution, I believe, is to have the function return a pair
of indeces, and then take the slice at the call site.