"Daniel Keep" <daniel.keep.lists@gmail.com> wrote in message news:gmrfe8$10l4$1@digitalmars.com...
> Nick Sabalausky wrote:
>> "Daniel Keep" <daniel.keep.lists@gmail.com> wrote in message news:gmpd71$8uj$1@digitalmars.com...
>
> Took me a while to find it, even knowing what it was about.  Ended up having to manually go through the digitalmars.com archives. :P
>
> http://www.digitalmars.com/d/archives/digitalmars/D/38329.html
>
> It's probably somewhat anachronistic now.  For anyone who isn't aware, back in the old days, 'scope' was 'auto' whilst 'auto' was 'auto.'  It sort of did two things and was a bit confusing.  Just replace 'auto' with 'scope' and you should be fine.  :P
>

Interesting. I'd love to see this get some more attention and discussion simply because what you had said earlier is also one of my own pet peeves about D, and I couldn't have descrbed it any better than you did:

>>> Given that one of D's tenets is to make it simpler to write deterministic, bullet-proof code, the complete lack of deterministic destruction of classes has always felt like a huge hole in the language.

Denis Koroskin wrote:
> Christopher Wright Wrote:
>> Any case in which the default constructor has side effects or preconditions is a problem.
> 
> 1) It is a valid C++ construct, and I don't remember having any problem with it.
> 
> 2) It's just a shortcut for Foo foo = new Foo(). If you don't plan to instanciate the instance immediately, i.e. you want to leave it as null, you should mark it as nullable:
> 
> Foo? foo; // no ctor call made

Okay, so your proposal relies on the nullable types proposal, which I dislike; and given the nullable types proposal, this is reasonable.

Andrei Alexandrescu, el  9 de febrero a las 22:20 me escribiste:
> Chad J wrote:
> >Andrei Alexandrescu wrote:
> >>Chad J wrote:
> >>>Besides safety concerns, what does forbidding manual deletion enable GC implementations to do?
> >>Foregoing delete affords the GC more implementation options.
> >>
> >>Andrei
> >Such as?
> >I'm not trying to be antagonistic--manual deletion is a nifty feature to
> >me, so if it gets designed away I'd appreciate knowing what great
> >advantages justified such a sacrifice.
> 
> You need to simply go through a good tutorial on GC implementations, and consider the added costs of offering a manual delete primitive.

I did read "Garbage Collection: Algorithms for Automatic Dynamic Memory
Management"[1] (several times =P) and some papers on the subject and
I honestly don't recall any big issues about it. The only case I can think
of if copy/compacting collectors that use the heap as a stack when
allocating, where freeing a cell in the middle clearly breaks the stack
allocation.

But in such cases I think delete could be a NOP, just like for now
genCollect() really do a fullCollect() because no generational collection
is present at the moment, the interface is there.

[1] http://www.cs.kent.ac.uk/people/staff/rej/gcbook/gcbook.html

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
More people die from a champagne-cork popping,
than from poison spiders

Leandro Lucarella wrote:
> Andrei Alexandrescu, el  9 de febrero a las 22:20 me escribiste:
>> Chad J wrote:
>>> Andrei Alexandrescu wrote:
>>>> Chad J wrote:
>>>>> Besides safety concerns, what does forbidding manual deletion enable GC
>>>>> implementations to do?
>>>> Foregoing delete affords the GC more implementation options.
>>>>
>>>> Andrei
>>> Such as?
>>> I'm not trying to be antagonistic--manual deletion is a nifty feature to
>>> me, so if it gets designed away I'd appreciate knowing what great
>>> advantages justified such a sacrifice.
>> You need to simply go through a good tutorial on GC implementations, and consider the added costs of offering a manual delete primitive.
> 
> I did read "Garbage Collection: Algorithms for Automatic Dynamic Memory
> Management"[1] (several times =P) and some papers on the subject and
> I honestly don't recall any big issues about it. The only case I can think
> of if copy/compacting collectors that use the heap as a stack when
> allocating, where freeing a cell in the middle clearly breaks the stack
> allocation.

The only issue I see is with copying garbage collectors. But even then, it would be possible to introduce a "force garbage" flag, which causes the collector to ignore a mark bit.

Also, D will never ever get a copying garbage collector (except if it's ported to .net, which would break everything else too), so why care about it?

> But in such cases I think delete could be a NOP, just like for now
> genCollect() really do a fullCollect() because no generational collection
> is present at the moment, the interface is there.
> 
> [1] http://www.cs.kent.ac.uk/people/staff/rej/gcbook/gcbook.html
> 

grauzone wrote:
> 
> Also, D will never ever get a copying garbage collector (except if it's ported to .net, which would break everything else too), so why care about it?
> 

Never is a strong word!  Though even if D did get a copying collector it would be come kind of hybrid that also has a conservative collector for backup.  Of course we'll probably be on D 4.0 (or later) by the time that happens.  Whatever.