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
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
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
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.
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
kOn Wed, 29 Jan 2014 05:55:56 -0500, Cooler kul...@hotbox.ru 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); //
On Thu, 30 Jan 2014 09:18:40 -0500, Cooler kul...@hotbox.ru 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
On Thu, 30 Jan 2014 09:07:14 -0500, Cooler kul...@hotbox.ru 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.
On Thu, 30 Jan 2014 10:24:14 -0500, Cooler kul...@hotbox.ru 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
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}
On Thu, 30 Jan 2014 10:49:34 -0500, Cooler kul...@hotbox.ru wrote:
On Thursday, 30 January 2014 at 15:29:50 UTC, Steven Schveighoffer wrote:
On Thu, 30 Jan 2014 10:24:14 -0500, Cooler kul...@hotbox.ru wrote:
On Thursday, 30 January 2014 at 14:40:36 UTC, Dicebot wrote:
I agree. I just want
On Thu, 30 Jan 2014 11:48:50 -0500, Cooler kul...@hotbox.ru 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
On Thu, 30 Jan 2014 12:07:07 -0500, Cooler kul...@hotbox.ru 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
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
On Thu, 30 Jan 2014 12:38:57 -0500, Cooler kul...@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
On Thu, 30 Jan 2014 13:58:55 -0500, Cooler kul...@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
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
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
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 over
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 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
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
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
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 in
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 in
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
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 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
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:
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().
30 matches
Mail list logo
