bearophile Wrote:

> Some functions need to do everything on a given array, while in other functions I just want to change the array contents. How can the source analyzer tell them apart and show some warnings only on the second kind of functions, without specific annotations?

It will check them indiscriminately. There's little need to overwrite input parameters. Input parameters are by nature likely to be read, overwriting them usually means you lose them, and losing parameters that are likely to be read is a bad practice, so it's a good idea to check for it.

Kagamin:

> It will check them indiscriminately. There's little need to overwrite input parameters.

If I don't need to overwrite an input array I usually tag it with "in" or "const", so your idea doesn't help me.

Bye,
bearophile

Am 31.08.2011, 20:27 Uhr, schrieb Kagamin <spam@here.lot>:

> bearophile Wrote:
>
>> Some functions need to do everything on a given array, while in other functions I just want to change the array contents. How can the source analyzer tell them apart and show some warnings only on the second kind of functions, without specific annotations?
>
> It will check them indiscriminately. There's little need to overwrite input parameters. Input parameters are by nature likely to be read, overwriting them usually means you lose them, and losing parameters that are likely to be read is a bad practice, so it's a good idea to check for it.

I had some of these cases in my JavaScript code where I process the parameter before I use it. But I'm now listening to Eclipse's advice and give them proper variables. So zoom becomes effectiveZoom and so on. But I guess it is a matter of preference. It is like Delphi's "Result" variable in functions that you can write to several times until you have your final output. Likewise people sometimes modify the input until they've got what they want. Clamping numbers, prefixing strings or replacing default/null values are use cases.

Marco Leise:

> Likewise people sometimes modify the input until they've got what they want. Clamping numbers, prefixing strings or replacing default/null values are use cases.

Think about an in-place sort routine. I give an array to it, and its items get shuffled, but nowhere inside the sort routine I want the array length to change. I'd like the array length to be const, but the array items to be mutable. In Phobos there are other examples of in-pace array functions. A system language offers such freedom too.

Bye,
bearophile

Am 31.08.2011, 21:44 Uhr, schrieb bearophile <bearophileHUGS@lycos.com>:

> Marco Leise:
>
>> Likewise people sometimes modify the input until they've got what
>> they want. Clamping numbers, prefixing strings or replacing default/null
>> values are use cases.
>
> Think about an in-place sort routine. I give an array to it, and its items get shuffled, but nowhere inside the sort routine I want the array length to change. I'd like the array length to be const, but the array items to be mutable. In Phobos there are other examples of in-pace array functions. A system language offers such freedom too.
>
> Bye,
> bearophile

Yeah I was specifically talking about a warning when you overwrite the parameter, not modify it's properties or content. It's probably a good idea to keep parameters 'head-const' by convention in every case unless they are out parameters.
You want the array to be partially modifiable or - regarding length and ptr - head-const so routines meant to work on the content only can be forced to do so. But then the next thing I would request is the same for other ranges. And ranges can be classes, too. I don't think the concept can work out if you want to process all ranges the same way in sorting algorithms and the like.

dsimcha:

> Have we considered the obvious library head-const solution?

Yeah. This code seems to work. The main disadvantage is that you have to convert the dynamic array to Hconst before passing it to the function, while the syntax I have suggested is transparent for the caller.

Another disadvantage is that this doesn't support nD arrays well (only the first dimension is head const).


import std.traits, std.stdio, std.conv;

struct Hconst(T) {
    private T[] data__;
    alias data__ this;
    @property size_t length() { return data__.length; }
    @property T* ptr() { return data__.ptr; }
    string toString() { return text(data__); } // ?
}

Hconst!(typeof(TA[0])) hconst(TA)(TA array) if (isDynamicArray!TA) {
    return typeof(return)(array);
}

// Overload: hconst(hconst(new int[10])) === hconst(new int[10])

void main() {
    auto a = new int[10];
    Hconst!int ha = hconst(a);
    ha.ptr[0] = 1;
    writeln(ha);
    ha[1] = 2;
    writeln(ha);
    writeln(ha.length);
    // ha.length += 1; // error, OK
}


Bye,
bearophile

Another disadvantage I didn't consider is that a Hconst!T converts silently to T[], so if you give a function, the function is free to ignore the const nature of ptr/length:


struct Foo(T) {
    private T[] data__;
    alias data__ this;
}

void bar1(Foo!int ha) {}
void bar2(int[] a) {}

void main() {
    Foo!int fa = Foo!int(new int[10]);
    bar1(fa); // OK
    bar2(fa); // OK
    //bar1(new int[10]); // NO
    int[] a = Foo!int(new int[10]); // OK
}

I didn't know this about alias this. I presume it is working as designed.

Bye,
bearophile

On Thu, 01 Sep 2011 13:48:25 +0200, bearophile <bearophileHUGS@lycos.com> wrote:

> Another disadvantage I didn't consider is that a Hconst!T converts silently to T[], so if you give a function, the function is free to ignore the const nature of ptr/length:
>
>
> struct Foo(T) {
>     private T[] data__;
>     alias data__ this;
> }
>
> void bar1(Foo!int ha) {}
> void bar2(int[] a) {}
>
> void main() {
>     Foo!int fa = Foo!int(new int[10]);
>     bar1(fa); // OK
>     bar2(fa); // OK
>     //bar1(new int[10]); // NO
>     int[] a = Foo!int(new int[10]); // OK
> }
>
> I didn't know this about alias this. I presume it is working as designed.
>
> Bye,
> bearophile

Somewhat surprising from time to time and one of the downsides of alias this.
The proposed HeadConst was aliasing to an rvalue, so even with conversion
you can't change the length.

martin