confusing (buggy?) closure behaviour

[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 argument n
>>> outside the enclosing function, then, IMO, RETURNING it (but not
>>> otherwise using it) should be flagged a compilation error.
>>> Admittedly, detecting this is a bit more involved for the compiler,
>>> but not at all restrictive for the user.
>>> 
>> D2.0 handles it all correctly. D1.0 follows the "hear is a gun, there
>> is your foot" mentality with regards to this. In general D is *not* a
>> safe language and that is by intent.
>> 
> 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?)
> 

In that (and only that) regards, D is closer to Ada than C++

http://adrianhoe.com/adrianhoe/2006/08/04/shooting-yourself-in-the-foot-a-humorous-approach-in-comparing-ada-to-other-programming-languages/

you can do it, it's just a bit had to do it on accident.

> 
> Does the "D is unsafe by intention" relate to D2.0, too?

D is intentionally not safe (vs. un-safe where the compiler requiter you 
to install a foot shooter mechine and does the shooting for you)

>