On Thu, 30 Jan 2014 12:38:57 -0500, Cooler <kulkin@hotbox.ru> wrote:


>>> The D principle - "The program compile and runs as expected, or not compile at all".
>>
>> This is a fantasy. The compiler cannot know what you expect.
> The language is needed to express your intentions to the compiler.

Anything that the compiler cannot enforce is just documentation. Does it matter whether the documentation is in a comment or part of the signature?

> The language should be expressive as possible. My point is to push programmers to write correct software. I just ask these forum to think about topic. If everybody satisfied by void fun(int[] x){} behavior, then I just go...

I'm not trying to be a bully or anything, but you are not understanding that what you want is a guarantee of logic, that the compiler cannot possibly enforce. Your example (setting a variable to another value) being rejected is easy to work around, just use another variable that doesn't have that restriction. There are so many examples of behavior-enforcing features that result in something that the creator of the feature didn't want or expect. Keep in mind there are years of projects that have been written assuming that you can use a standard slice in the signature of a function, we don't want to invalidate all that code just because programmers sometimes write buggy code.

> But I encounter a bug in my program that was due to my misusing of such signature.

Here's where the gray area is. If you make this error once or twice, but never again, is it worth changing the language over? Probably not. But if you make this error every day, even KNOWING what will happen, it's worth looking into. But any changes have to avoid a negative impact on existing code as much as possible. Think of the person who knows how slices work, who very seldom makes this mistake, and who now has to go through all his code and make this change, never finding an instance where it makes a difference.

At this point, I'm not sure what you are proposing, but I don't think there is much value in changing the way slice passing works.

>>> If you really need to call function that can change content of an array, but cannot change size of an array the language syntax should allow express it in function signature. I consider "void fun(int[] const x){}" more error prone than "void fun(int[] x){}" and for the caller and for implemeter.
>>
>> Not sure if something is mixed up there. I think void fun(int[] x) is sufficient to describe what you say. The function cannot alter x's array bounds at all, and can alter it's data.
>>
> Here is the reason why i post the topic on this forum. You think one way, I think another way. I wanted to discuss what think other people. But looks like still nobody can understand my point, or may be I cannot express it...

By mixed up, I meant that you seemed to be valuing the int[] x version over the int[] const x version.

Other than that, what I stated is an indisputable fact -- the function cannot alter x's bounds.

-Steve

>>>> The D principle - "The program compile and runs as expected, or not compile at all".
>>>
>>> This is a fantasy. The compiler cannot know what you expect.
>> The language is needed to express your intentions to the compiler.
>
> Anything that the compiler cannot enforce is just documentation. Does it matter whether the documentation is in a comment or part of the signature?
Why we need "const" keyword, while we can just put "I promise do not change it" in the documentation?

>
>> The language should be expressive as possible. My point is to push programmers to write correct software. I just ask these forum to think about topic. If everybody satisfied by void fun(int[] x){} behavior, then I just go...
>
> I'm not trying to be a bully or anything, but you are not understanding that what you want is a guarantee of logic, that the compiler cannot possibly enforce.
I am telling to the compiler what to do, or what not to do, with help of programming language. I am controlling the compilation result with the language. I am not waiting that compiler will anticipate my thoughts. But if I write "const x" the variable must be const. If i have language construct that can give me stronger guarantees, i will use it.

> Your example (setting a variable to another value) being rejected is easy to work around, just use another variable that doesn't have that restriction.
My goal is not to implement some functionality, and I don't know how to do it.
I want to make programmer's intentions more clear with a help of language.
What you are saying is approximately - "If everybody will tune the language to his private needs, it will be not good". I agree with such point. Therefore I asked in the forum - am I alone who wants to tune this language feature? If you are experienced programmer in D your brain filter such cases automatically.

> There are so many examples of behavior-enforcing features that result in something that the creator of the feature didn't want or expect. Keep in mind there are years of projects that have been written assuming that you can use a standard slice in the signature of a function, we don't want to invalidate all that code just because programmers sometimes write buggy code.
>
I don't even thought to invalidate already written code.

>> But I encounter a bug in my program that was due to my misusing of such signature.
>
> Here's where the gray area is. If you make this error once or twice, but never again, is it worth changing the language over? Probably not. But if you make this error every day, even KNOWING what will happen, it's worth looking into. But any changes have to avoid a negative impact on existing code as much as possible. Think of the person who knows how slices work, who very seldom makes this mistake, and who now has to go through all his code and make this change, never finding an instance where it makes a difference.
>
> At this point, I'm not sure what you are proposing, but I don't think there is much value in changing the way slice passing works.
>
>>>> If you really need to call function that can change content of an array, but cannot change size of an array the language syntax should allow express it in function signature. I consider "void fun(int[] const x){}" more error prone than "void fun(int[] x){}" and for the caller and for implemeter.
>>>
>>> Not sure if something is mixed up there. I think void fun(int[] x) is sufficient to describe what you say. The function cannot alter x's array bounds at all, and can alter it's data.
>>>
>> Here is the reason why i post the topic on this forum. You think one way, I think another way. I wanted to discuss what think other people. But looks like still nobody can understand my point, or may be I cannot express it...
>
> By mixed up, I meant that you seemed to be valuing the int[] x version over the int[] const x version.
>
> Other than that, what I stated is an indisputable fact -- the function cannot alter x's bounds.
>
> -Steve

On Thu, 30 Jan 2014 13:58:55 -0500, Cooler <kulkin@hotbox.ru> wrote:

>>>>> The D principle - "The program compile and runs as expected, or not compile at all".
>>>>
>>>> This is a fantasy. The compiler cannot know what you expect.
>>> The language is needed to express your intentions to the compiler.
>>
>> Anything that the compiler cannot enforce is just documentation. Does it matter whether the documentation is in a comment or part of the signature?
> Why we need "const" keyword, while we can just put "I promise do not change it" in the documentation?

const is only useful in cases where references are involved. In this case, you want to make the *copied* data constant, in hopes that you then can't accidentally stop referencing the original.

In another example, there is little to be gained from a signature such as:

void foo(const int x);

What does this say about foo? Nothing. I can pass in a mutable, const, or immutable int, because a copy is made. It doesn't provide any more guarantees to the caller than:

void foo(int x);

Likewise, your proposed "int[] const" would not guarantee anything extra to the caller beyond "int[]", because both are copies put onto the stack. The function has no access to the original values.

Arrays in D are hard to understand. They don't behave like arrays in most other languages. But they foster a different mindset I think, that results in some of the fastest code on the planet. But one has to understand the semantics of syntax if they want to properly use the language. For functions which append/extend and then write data to the prior piece (the only non-deterministic case), special care has to be taken to explain this to the caller. I would think a mechanism to attempt detecting this and flagging it would be a worthy lint tool feature. But not a language or compiler feature. There is just simply no way to say "that is always bad" or that you know what the intentions of the author are.

The other case you specified, when the author re-assigns a slice and expects it to be a memcpy or to re-bind the calling parameter, the result is deterministically the wrong result, and the coder will notice it right away (and hopefully correct their understanding). I don't think we need a language feature for that, just documentation (which I think we have).

Let me also suggest you use scope statements to verify at runtime that the case you intend to prevent doesn't actually happen:

void foo(int[] x)
{
   const origx = x;
   scope(exit) assert(origx.ptr == x.ptr);
   ...
}

While not perfect, and not static, it should at least avoid subtle bugs (and can be turned off in release mode).

-Steve

On Wednesday, 29 January 2014 at 10:55:57 UTC, Cooler wrote:
> Consider 3 functions taking array as an argument:
>
> void fun1(in  int[] x){...}
> void fun2(ref int[] x){...}
> void fun3(    int[] x){...}
>
> auto a = new int[10];
>
> fun1(a); // Guaranteed that "a" will not be changed
> fun2(a); // Guaranteed that we will see any change to "a", made in fun2()
> fun3(a); // Changes to "a" in fun3() may be or may be not visible to the caller
>
> In case of fun3() we have ambiguous behaviour, depending on the body of the function.
>
> Am I right?
> Is that intentional?

I believe what you are asking for is "head const." D does not do this, search for "head const dlang" and you'll probably find some discussion in it.