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 *safe* language, but without the overkill of a Java VM or .NET runtime. My hope was with D, but you seem to be convincing me otherwise...
> > 
> > Does the "D is unsafe by intention" relate to D2.0, too?
> 
> 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 unsafe.

As for the safe/unsafe and system language matter:

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".

I think, providing unsafe features through clumsy syntax makes things worse, because it reduces readability where readability is most wanted - in sensible, unsafe places (think "code reviews").

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.?

Thx for taking the time!

> In this case, D1 fails. D2 works, though at the cost of additional, often unnecessary, heap allocation. Since D is a systems language, this is not good and is due to change soon. At least, I think Walter said he plans to implement scope delegates in D2.

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)

> 

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 programming so fun?" went on for several days on religion of all things)

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 the closure is being returned (it is). The compiler should IMO then generate an error (or warning) about the return statement, perhaps stating something like "cannot return a delegate that refers to variables in local scope", or something like that.

There was a long discussion on this topic.  See
http://www.digitalmars.com/d/archives/digitalmars/D/Escape_analysis_78791.html
for an insight.  To summarize, it's almost always potentially unsafe to
use stack closures.  For instance, if you pass closure to a function,
that function can save that closure to a global variable, so the closure
outlives the container function without being explicitly returned.  If
compiler forbids any potentially unsafe use of closures, it would make
them next to useless and also would break lots of valid code, for
instance a significant part of Tango library.