confusing (buggy?) closure behaviour

[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 *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.