On Saturday, 2 May 2015 at 18:02:34 UTC, Idan Arye wrote:
On Friday, 1 May 2015 at 21:42:22 UTC, deadalnix wrote:
On Friday, 1 May 2015 at 17:51:05 UTC, Walter Bright wrote:
On 4/30/2015 5:55 AM, Vladimir Panteleev wrote:
I think Freddy's programs are working as designed.
Yes, they are.
D c
On Friday, 1 May 2015 at 21:42:22 UTC, deadalnix wrote:
On Friday, 1 May 2015 at 17:51:05 UTC, Walter Bright wrote:
On 4/30/2015 5:55 AM, Vladimir Panteleev wrote:
I think Freddy's programs are working as designed.
Yes, they are.
D closures capture variables by reference. No, we're not
chan
On Saturday, 2 May 2015 at 03:35:17 UTC, ketmar wrote:
if js doing something, big chances are that it's wrong. Brendan
failed
his Scheme classes, especially those where he was taught about
closures.
Here's another fun thing about javascript:
a = new Number(1);
b = new Number(1);
a<=b; // true
On Fri, 01 May 2015 18:08:07 +, Adam D. Ruppe wrote:
> Javascript does D's current behavior, so I thought it was correct too,
if js doing something, big chances are that it's wrong. Brendan failed
his Scheme classes, especially those where he was taught about closures.
signature.asc
Descrip
On Saturday, 2 May 2015 at 00:55:19 UTC, Adam D. Ruppe wrote:
On Friday, 1 May 2015 at 21:46:15 UTC, deadalnix wrote:
No it does not. In JS, var declare a variable at function
level, so that is why you see the behavior you see.
Yes, I know, I said that a short while down in that post.
Saw th
On Friday, 1 May 2015 at 21:46:15 UTC, deadalnix wrote:
No it does not. In JS, var declare a variable at function
level, so that is why you see the behavior you see.
Yes, I know, I said that a short while down in that post.
On Friday, 1 May 2015 at 18:08:09 UTC, Adam D. Ruppe wrote:
Javascript does D's current behavior, so I thought it was
correct too, but C# doesn't it that way.
No it does not. In JS, var declare a variable at function level,
so that is why you see the behavior you see.
Since JS 1.7, you can d
On Friday, 1 May 2015 at 17:51:05 UTC, Walter Bright wrote:
On 4/30/2015 5:55 AM, Vladimir Panteleev wrote:
I think Freddy's programs are working as designed.
Yes, they are.
D closures capture variables by reference. No, we're not
changing that.
The variable is declared in the block, there
On 5/1/2015 11:08 AM, Adam D. Ruppe wrote:
There, I say it is expected because a longstanding bug is expected to work
around but that doesn't make it *right*.
I did agree in the bug report on that that it was a bug.
On Friday, 1 May 2015 at 17:51:05 UTC, Walter Bright wrote:
Yes, they are.
I thought this until just a couple weeks ago when I was shown to
be pretty conclusively wrong. See the discussion here:
https://issues.dlang.org/show_bug.cgi?id=2043
When a new scope is introduced, a new variable is
On 4/30/2015 5:55 AM, Vladimir Panteleev wrote:
I think Freddy's programs are working as designed.
Yes, they are.
D closures capture variables by reference. No, we're not changing that.
On Thursday, 30 April 2015 at 12:55:18 UTC, Vladimir Panteleev
wrote:
On Thursday, 30 April 2015 at 12:01:32 UTC, Marc Schütz wrote:
On Thursday, 30 April 2015 at 05:23:55 UTC, Vladimir Panteleev
wrote:
On Thursday, 30 April 2015 at 03:58:44 UTC, Freddy wrote:
On Thursday, 30 April 2015 at 01:1
On Thu, 30 Apr 2015 12:55:16 +, Vladimir Panteleev wrote:
> D closures should work in the same way as, e.g., JS closures.
js closures are fubared.
signature.asc
Description: PGP signature
On 04/30/2015 05:55 AM, Vladimir Panteleev wrote:
> D closures should work in the same way as, e.g., JS closures. Try
> rewriting the program in JavaScript. If it behaves in the same way, it's
> not a D bug.
Right.
I remember Seth Ladd's Dart language presentation at the local ACCU in
Silicon
On Thursday, 30 April 2015 at 12:01:32 UTC, Marc Schütz wrote:
On Thursday, 30 April 2015 at 05:23:55 UTC, Vladimir Panteleev
wrote:
On Thursday, 30 April 2015 at 03:58:44 UTC, Freddy wrote:
On Thursday, 30 April 2015 at 01:19:45 UTC, Vladimir
Panteleev wrote:
Because "copy" is still modified
On Thursday, 30 April 2015 at 05:23:55 UTC, Vladimir Panteleev
wrote:
On Thursday, 30 April 2015 at 03:58:44 UTC, Freddy wrote:
On Thursday, 30 April 2015 at 01:19:45 UTC, Vladimir Panteleev
wrote:
Because "copy" is still modified every time "i" is.
But shouldn't copy be redeclared every loop i
On Thursday, 30 April 2015 at 03:58:44 UTC, Freddy wrote:
On Thursday, 30 April 2015 at 01:19:45 UTC, Vladimir Panteleev
wrote:
Because "copy" is still modified every time "i" is.
But shouldn't copy be redeclared every loop iteration (or the
compiler could pretend to redeclare it).
No, it wil
On Thursday, 30 April 2015 at 01:19:45 UTC, Vladimir Panteleev
wrote:
Because "copy" is still modified every time "i" is.
But shouldn't copy be redeclared every loop iteration (or the
compiler could pretend to redeclare it).
I understand that
import std.stdio;
void main(){
int delegate() func;
foreach(i;0..10){
if(i==5){
func= () => i;
}
}
writeln(func());//9
}
captures the loop variable,but why does
import std.stdio
On Thursday, 30 April 2015 at 01:16:20 UTC, Freddy wrote:
I understand that
import std.stdio;
void main(){
int delegate() func;
foreach(i;0..10){
if(i==5){
func= () => i;
}
}
writeln(func());//9
}
ca
20 matches
Mail list logo
