lol.

but if your doc said that to you, you'd go somewhere else for a second opinion.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:b3pb16$q7h$1@digitaldaemon.com...
> Mike Wynn wrote:
> > just like the code I posted before (returning a slice from static array)
> > this is just another way for the unwary to scrible on the stack
> > yet again I am confused by the direction that D is progressing more
features
> > are being added and each adds more pit falls rather than removing them.
to
> > anyone who has used (dare I mention it) Perl, Java or Scheme might not expect the dangers that lurk within the use of inner functions as
delegates.
> > in 90% of the projects I've worked on robustness and ability to prove robustness where more important than speed, so I'm a bit anti features
that
> > would adversly effect potential changes to the code they call.
>
> This reminds me of an ancient joke.  Guy in an appointment with his doctor says "Doc, it hurts when I do this."  Doctor replies, "Well, don't do that."
>

[this might double-post]

Mike Wynn wrote:
> lol.
> 
> but if your doc said that to you, you'd go somewhere else for a second
> opinion.
> 
> "Burton Radons" <loth@users.sourceforge.net> wrote in message
> news:b3pb16$q7h$1@digitaldaemon.com...
> 
>>This reminds me of an ancient joke.  Guy in an appointment with his
>>doctor says "Doc, it hurts when I do this."  Doctor replies, "Well,
>>don't do that."

The point is that you're ignoring the difference between
constant and aggravated pain.  Those coming from another language where
their prejudices are incompatible might try writing nested delegates
incorrectly, but they'll get burned and adjust their practices to never
do that again.  When used properly, the feature as-is is helpful, and is applicable to a range of jobs that is not entirely a subset to full closures - I wouldn't be able to apply them as vigorously if they caused allocations.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:b3ri0n$2iq4$1@digitaldaemon.com...
> [this might double-post]
>
> Mike Wynn wrote:
> > lol.
> >
> > but if your doc said that to you, you'd go somewhere else for a second opinion.
> >
> > "Burton Radons" <loth@users.sourceforge.net> wrote in message news:b3pb16$q7h$1@digitaldaemon.com...
> >
> >>This reminds me of an ancient joke.  Guy in an appointment with his doctor says "Doc, it hurts when I do this."  Doctor replies, "Well, don't do that."
>
> The point is that you're ignoring the difference between
> constant and aggravated pain.  Those coming from another language where
> their prejudices are incompatible might try writing nested delegates
> incorrectly, but they'll get burned and adjust their practices to never
> do that again.  When used properly, the feature as-is is helpful, and is
> applicable to a range of jobs that is not entirely a subset to full
> closures - I wouldn't be able to apply them as vigorously if they caused
> allocations.
>
it was a joke :)

I'm not ignoring it what conserns me is the way you get burned, a performance hit is one thing, even getting an incorrect value is not so bad as long as its at the place where you make the call, but rewriting the stack which might contain a return location, is something that ideally should not be possible (without doing something that is obviously abusive) as it can go off a long time after the call that caused it and can be hard to track down even with a good debugger.

I don't deny that it is a powerful and useful feature (like array slicing) but like returning a slice from an array on the stack

would you consider D allowing non virtual destructors as C++ does ?

maybe I've got the wrong impession of what D is, I got the impression that it was a language with a C like syntax that would allow me to write a program if it compiled and I ran it and got the wrong result, then it was my algorythm that was wrong and not my coding if I tried to do something that was not safe then I'd get an assert or exception.

what is needed is for the delegate to be marked as auto (i.e. refers [in
someway] to an item on a parent stack frame) so it can only be used, or
passed as a param (auto only), but never stored.

as I said before my primary consern is robustness (and its proveabilty) and
not raw performance, second is ability to produce stand alone applications
that do not require any other libraries or runtimes (so .NET and Java are
not applicable).
which leaves C/C++ or delphi/Kylix   delphi is a little more robust than C
but lacks GC.
I accept that I may be a robustness bigot but who wants a fast program that
randomly crashes.

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:b40fkm$252h$1@digitaldaemon.com...
> what is needed is for the delegate to be marked as auto (i.e. refers [in
> someway] to an item on a parent stack frame) so it can only be used, or
> passed as a param (auto only), but never stored.

Actually, I have figured out a way to make a runtime check on that which will prevent erroneous use.