Why I can't use array in compile-time struct creation?

2008-12-13 Thread Weed
It is forbidden by specification, but an interesting reason. for example: struct S { static S opCall() { S res; int a,b,c,d; int[10] data; // If I comment out this line compilation goes smoothly return res; } } void main() { static S s = S(); }

Re: confusing (buggy?) closure behaviour

2008-12-13 Thread Sergey Gromov
Sat, 13 Dec 2008 06:59:51 -0500, Zoran Isailovski wrote: > Anyway, following the latter pattern, you don't need global analysis. > You can determine if n is on the stack (it is - it's an argument), > you can determine if it's referenced from within the closure (it is), > and you can determine if t

Re: confusing (buggy?) closure behaviour

2008-12-13 Thread bearophile
Zoran Isailovski: > I like the approach of Ada, Oberon, and (I think) Modula-3 - all of which > have successfully been used for system programming - in that they allow > unsafe constructs ONLY in modules specifically marked as "unsafe".< This is already becoming true in the last version of DMD.

Re: confusing (buggy?) closure behaviour

2008-12-13 Thread BCS
Reply to Zoran, Christopher Wright Wrote: I'd rather stop here, because this is probably not the place to discuss these things. But perhaps you can direct me to a discussion group or sth.? Don't worry, This NG has a long standing tradition of epic rambling OT threads ("[~ot] why is programm

Re: confusing (buggy?) closure behaviour

2008-12-13 Thread BCS
Reply to Zoran, BCS Wrote: Reply to Zoran, I don't think it is restrictive if the compiler prevented a situation that would otherwise lead to a run-time error anyway, or worse, weird and confusing run-time behavior. In my case, if the compiler couldn't SAFELY handle a reference to the argume

Re: confusing (buggy?) closure behaviour

2008-12-13 Thread Zoran Isailovski
Christopher Wright Wrote: > Zoran Isailovski wrote: > > Oh... I've got the wrong impression from the papers about D. (But then, why > > would someone design an *unsafe* language *by intention*??? For that, we've > > got C and C++, don't we?) > > > > Anyway, I've been looking for a modern and *s

Re: confusing (buggy?) closure behaviour

2008-12-13 Thread Zoran Isailovski
Simen Kjaeraas Wrote: > Zoran Isailovski wrote: > > > Oh... I've got the wrong impression from the papers about D. (But then, > > why would someone design an *unsafe* language *by intention*??? For > > that, we've got C and C++, don't we?) > > Because we want D to be the new C/C++? :p > >

Re: confusing (buggy?) closure behaviour

2008-12-13 Thread Jarrett Billingsley
On Sat, Dec 13, 2008 at 9:09 AM, Christopher Wright wrote: > D tries to make it easy to do the safe thing. It's a systems language, so it > has to allow you to do unsafe things without too much trouble -- but usually > with some not-too-pretty syntax to indicate that you're doing something > unsaf

Re: confusing (buggy?) closure behaviour

2008-12-13 Thread Christopher Wright
Zoran Isailovski wrote: Oh... I've got the wrong impression from the papers about D. (But then, why would someone design an *unsafe* language *by intention*??? For that, we've got C and C++, don't we?) Anyway, I've been looking for a modern and *safe* language, but without the overkill of a J

Re: confusing (buggy?) closure behaviour

2008-12-13 Thread Zoran Isailovski
Sergey Gromov Wrote: > Fri, 12 Dec 2008 15:24:39 -0500, Zoran Isailovski wrote: > > > Denis Koroskin Wrote: > > > On Fri, 12 Dec 2008 19:32:03 +0300, Zoran Isailovski > wrote: > > > I'm an experienced C#, Java and Python programmer, and have employed > > closures (and C

Re: confusing (buggy?) closure behaviour

2008-12-13 Thread Simen Kjaeraas
Zoran Isailovski wrote: Oh... I've got the wrong impression from the papers about D. (But then, why would someone design an *unsafe* language *by intention*??? For that, we've got C and C++, don't we?) Because we want D to be the new C/C++? :p D is unsafe in that it lets you shoot yourse

Re: confusing (buggy?) closure behaviour

2008-12-13 Thread Zoran Isailovski
BCS Wrote: > Reply to Zoran, > > > I don't think it is restrictive if the compiler prevented a situation > > that would otherwise lead to a run-time error anyway, or worse, weird > > and confusing run-time behavior. In my case, if the compiler couldn't > > SAFELY handle a reference to the argumen

Re: Freeing of memory (garbage collection)

2008-12-13 Thread Sergey Gromov
Tue, 9 Dec 2008 03:25:07 + (UTC), Dan W wrote: > 1: Even though D has an automatic garbage collector, is one still > allowed to free the memory of a malloced array manually (using free > () ), to avoid pauses in the program? Just to clarify. There are 3 types of allocation: 1. std.c.stdlib