const debacle

[Jarrod]

On Mon, 24 Mar 2008 10:50:16 +0000, Janice Caron wrote:

> 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/.

Well I'm not really 'against' Walter here myself. I'm merely pointing out 
that attempting to stick to const-correctness ends up putting a hole in 
one of the key uses of const.
I provided a suggestion that both keeps const-correctness yet also allows 
for a simpler contract to merely show your data is safe at least when 
being used by the function you are calling.

> 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?
>     }

I would like to know what someone is thinking if they make this function? 
If you were going to return anything that is going to potentially be 
const, then wouldn't you make 'a' const as well?
Why would you potentially screw yourself over like that? Sometimes the 
programmer needs to do the sanity checks.


> 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.

Again, not at all sure why you would do that, but yes it does mean you 
can return a slice of either. Does the current system have a better way 
to deal with this that my suggestion would break?


> 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.

Perhaps I have misunderstood the original issue, but the problem as far 
as I know is not that you can't return a slice of a const, nor is the 
issue that you cannot prove which array a returned slice belongs to. The 
issue is that you can only return a const slice of a const, even if it is 
only a temporarily const piece of data due to the function scoping it as 
such. Maybe I'm tired, but how does sliceof() fix this? =/