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 th
On Thu, 30 Jan 2014 13:58:55 -0500, Cooler 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
On Thu, 30 Jan 2014 12:38:57 -0500, Cooler 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 compile
On Thursday, 30 January 2014 at 16:48:51 UTC, Cooler wrote:
On Thursday, 30 January 2014 at 16:18:33 UTC, Steven
Schveighoffer wrote:
void foo(int x)
{
x = 5;
}
"hey, why doesn't that work! Setting a parameter to another
value should be illegal!"
-Steve
Please understand - I am not again
On Thu, 30 Jan 2014 12:07:07 -0500, Cooler wrote:
On Thursday, 30 January 2014 at 16:18:33 UTC, Steven Schveighoffer wrote:
void foo(int x)
{
x = 5;
}
"hey, why doesn't that work! Setting a parameter to another value
should be illegal!"
Difference is here.
"void foo(int x){}" - the c
On Thu, 30 Jan 2014 11:48:50 -0500, Cooler wrote:
Please understand - I am not against void foo(int[] x){}
From an earlier post by you:
May be just prohibit at language level the case of fun3() function, to
do not allow unpredictable behavior?
I thought that this meant you were against
On Thu, 30 Jan 2014 11:04:44 -0500, Cooler wrote:
On Thursday, 30 January 2014 at 16:01:32 UTC, Cooler wrote:
On Thursday, 30 January 2014 at 15:59:48 UTC, Cooler wrote:
On Thursday, 30 January 2014 at 15:51:44 UTC, Tobias Pankrath wrote:
On Thursday, 30 January 2014 at 15:49:35 UTC, Cooler
On Thu, 30 Jan 2014 10:49:34 -0500, Cooler wrote:
On Thursday, 30 January 2014 at 15:29:50 UTC, Steven Schveighoffer wrote:
On Thu, 30 Jan 2014 10:24:14 -0500, Cooler wrote:
On Thursday, 30 January 2014 at 14:40:36 UTC, Dicebot wrote:
I agree. I just want that the case can be expressed in
On Thursday, 30 January 2014 at 15:49:35 UTC, Cooler wrote:
I agree. I just want that the case can be expressed in
language syntax more obvious - something like "fun(int[]
const x){}" to emphasize that I understand that fun() can
change content of array, and cannot change the {pointer,size}
pa
On Thu, 30 Jan 2014 10:24:14 -0500, Cooler wrote:
On Thursday, 30 January 2014 at 14:40:36 UTC, Dicebot wrote:
On Thursday, 30 January 2014 at 13:42:53 UTC, Cooler wrote:
If I use fun2() I expect that fun2() will change the content of my
array, and all changes I will see. If I don't want any
On Thu, 30 Jan 2014 09:07:14 -0500, Cooler wrote:
If I don't want that fun() will change my array, i have to use fun1()
variant.
If I want fun() will change my array, i have to use fun2() variant. What
fun2() do with it's argument inside it's body - not my business.
No. You can use fun3 va
On Thu, 30 Jan 2014 09:18:40 -0500, Cooler wrote:
Forgot to mention :)
I read the rest of the discussion. Arrays are hard to understand in D,
especially if you have preconceived notions from other languages. But
I would point out that fun2 does not "guarantee" anything more than
fun3:
On Thursday, 30 January 2014 at 14:18:41 UTC, Cooler wrote:
"But I would point out that fun2 does not guarantee anything
more than fun3:" - fun2() cannot guarantee anything because it
calls fun3() which in turn cannot guarantee anything.
Unrelated.
void foo2(ref int[] arr)
{ /* do nothing */
On Thursday, 30 January 2014 at 14:40:36 UTC, Dicebot wrote:
On Thursday, 30 January 2014 at 13:42:53 UTC, Cooler wrote:
What should I want to use fun3()?
For changes to content of array but not array itself.
For zillion+nth time :)
On Thursday, 30 January 2014 at 13:42:53 UTC, Cooler wrote:
If I use fun2() I expect that fun2() will change the content of
my array, and all changes I will see. If I don't want any
change to my array, I will use fun1(). What should I want to
use fun3()?
For changes to content of array but no
kOn Wed, 29 Jan 2014 05:55:56 -0500, 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 wi
On Wednesday, 29 January 2014 at 14:34:54 UTC, Cooler wrote:
Here is ambiguity.
void fun3(int[] x){ x ~= 5; ... }
auto a = new int[10];
fun3(a); // Here content of "a" may be changed or may be not
changed. Depends on the buffer size that system will allocate
for "a" array.
You use very subjec
On Thursday, 30 January 2014 at 10:49:42 UTC, Cooler wrote:
Now I am trying to speak ideally. What ideal language should
be, not the practical implementation.
...
Again - don't look back. Consider how we can make D better.
...
Again - stop consider current state of D implementation.
Consid
Cooler:
Again - stop consider current state of D implementation.
Consider how we can make D better. I think fun3() push
programmers to make errors.
I think functions like void fun(int[] a){} are bug prone, because
you seem to change the length of the array inside the function,
or if you per
On Thursday, 30 January 2014 at 09:14:43 UTC, Cooler wrote:
If you want to modify the slice and make changes visible in
caller, you should use ref. If you don't care whether changes
are visible in caller, you can omit any attributes and use
plain array. This belongs to the case you are asking a
On Thursday, 30 January 2014 at 09:14:43 UTC, Cooler wrote:
Please stop explain me how fun3() works. I know that.
One of the main idea of D is that things must work as planned,
or would not compile at all. First and second variants follow
this idea. But fun3() can work not as planned on the ca
On Wednesday, 29 January 2014 at 16:26:05 UTC, Cooler wrote:
On Wednesday, 29 January 2014 at 16:15:36 UTC, Tobias Pankrath
wrote:
On Wednesday, 29 January 2014 at 16:01:08 UTC, Cooler wrote:
Do you read my post? I am answering... why do I need fun3()
if I already have fun1() and fun2().
fu
On Wednesday, 29 January 2014 at 16:26:05 UTC, Cooler wrote:
Where argument has the same length? After function call, or
inside function? I don't understand what my intention should be
to push me to use fun3()?
Where argument has the same length? After function call, or
inside function? I don'
On Wednesday, 29 January 2014 at 14:48:12 UTC, Cooler wrote:
If, however, in fun3 you change the size of the array - it may
reallocate. Like, if you're appending to `x` - it will
allocate a new array and make x point to it. Now `a` and `x`
point to distinct arrays. And any change you do using `
On Wednesday, 29 January 2014 at 16:54:27 UTC, Cooler wrote:
On Wednesday, 29 January 2014 at 16:36:44 UTC, Stanislav Blinov
wrote:
On Wednesday, 29 January 2014 at 16:26:05 UTC, Cooler wrote:
Where argument has the same length? After function call, or
inside function? I don't understand what
On Wednesday, 29 January 2014 at 16:26:05 UTC, Cooler wrote:
Where argument has the same length? After function call, or
inside function? I don't understand what my intention should be
to push me to use fun3()?
Gosh. To allow the function to modify the contents, but not the
size of the array
On Wednesday, 29 January 2014 at 16:01:08 UTC, Cooler wrote:
Do you read my post? I am answering... why do I need fun3() if
I already have fun1() and fun2().
fun3 guarantees that the argument has the same length for example.
On Wednesday, 29 January 2014 at 15:38:34 UTC, Cooler wrote:
It's not unpredictable, at least not more unpredictable then
fun2.
Should we dissallow this two?
int[] a = [1,2,3,4];
b = a;
b ~= [5, 6, 7, 8];
You don't understand me. You consider that I am author of the
fun() and the caller sid
On Wednesday, 29 January 2014 at 15:11:33 UTC, Cooler wrote:
Yes, that is how slices work in D. The following article
explains the "non-determinism" that you mention:
http://dlang.org/d-array-article.html
Ali
Thank you for the article.
Quotation from the article "It is a good idea to note i
On Wednesday, 29 January 2014 at 15:11:33 UTC, Cooler wrote:
Yes, that is how slices work in D. The following article
explains the "non-determinism" that you mention:
http://dlang.org/d-array-article.html
Ali
Thank you for the article.
Quotation from the article "It is a good idea to note i
On 01/29/2014 02:55 AM, 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 chan
On Wednesday, 29 January 2014 at 13:15:30 UTC, Cooler wrote:
On Wednesday, 29 January 2014 at 12:40:00 UTC, Tobias Pankrath
wrote:
On Wednesday, 29 January 2014 at 11:46:23 UTC, Cooler wrote:
Thank you for detailed explanation. But the question is - "Is
that correct that language allows ambiguo
On Wednesday, 29 January 2014 at 13:15:30 UTC, Cooler wrote:
On Wednesday, 29 January 2014 at 12:40:00 UTC, Tobias Pankrath
wrote:
On Wednesday, 29 January 2014 at 11:46:23 UTC, Cooler wrote:
Thank you for detailed explanation. But the question is - "Is
that correct that language allows ambiguo
On Wednesday, 29 January 2014 at 11:46:23 UTC, Cooler wrote:
Thank you for detailed explanation. But the question is - "Is
that correct that language allows ambiguous behavior?"
Where is it ambiguous?
On Wednesday, 29 January 2014 at 11:46:23 UTC, Cooler wrote:
Thank you for detailed explanation. But the question is - "Is
that correct that language allows ambiguous behavior?"
Could you expand your example?
fun(int[] a) {} is passing a by value, that is, the pointer and
length is copied ove
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 th
36 matches
Mail list logo
