• Adam Ruppe (23/23) Jan 14 2022 Currently calling .destroy(class_object) fails the @nogc tests.
• David Gileadi (2/3) Jan 14 2022 I see what you did there.
• H. S. Teoh (12/16) Jan 14 2022 It's a lucky coincidence. :D
• Elronnd (4/5) Jan 14 2022 Practical Q: how many people are using classes without gc? And
• evilrat (14/19) Jan 15 2022 I've used @nogc as simple diagnostic, shows where it can allocate
• Guillaume Piolat (4/9) Jan 15 2022 We the annoying audio people, runtime can't be enabled reliably
• Adam D Ruppe (4/6) Jan 15 2022 It can be done on dmd on Windows but is a pain. On all the other
• Guillaume Piolat (5/12) Jan 15 2022 IIRC: The remaining problem is on Linux, we absolutely want a
• Steven Schveighoffer (7/13) Jan 15 2022 Destructors can't allocate if running inside the GC. This makes them
• Stanislav Blinov (3/4) Jan 15 2022 Oh, that's here:
• Adam D Ruppe (14/15) Jan 15 2022 Yes, indeed. The current implementation is in part in compliance

Adam Ruppe <destructionator gmail.com> writes:

Currently calling .destroy(class_object) fails the  nogc tests. 
This is because the dynamic type of the object is not statically 
known and there's no restriction on child class destructors, so 
it has to assume the worst.

But what if the compiler simply inserted the call to super.dtor 
and all struct_member.dtors at the end of your destructor and did 
the attribute checks on them?

This would give you a chance to declare your more strict 
attributes while keeping everything in place - and any child 
class would no longer be able to loosen what's there. Meaning 
destroy(class_object) when the static type passed to destroy has 
a  nogc ~this, it'd be ok to propagate that up since it knows it 
all works, regardless of what chains get added.

If there is no dtor in a parent, there is no super call in the 
child, meaning it is also unrestricted and you can declare 
whatever you want.

if the dtor is all auto-generated and there is a super dtor, it 
inherits the attributes from super. If it is auto-generated and 
there is no super (meaning it just calls struct member dtors), it 
gets *no* attributes. Just because there's a  nogc struct member 
doesn't mean you should be locked in for child classes; I want it 
explicit if you want to opt into restrictions.

destroy!

David Gileadi <gileadisNOSPM gmail.com> writes:

On 1/14/22 4:28 PM, Adam Ruppe wrote:
 destroy!

I see what you did there.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Fri, Jan 14, 2022 at 06:31:21PM -0700, David Gileadi via Digitalmars-d wrote:
 On 1/14/22 4:28 PM, Adam Ruppe wrote:
 destroy!

 
 I see what you did there.

It's a lucky coincidence. :D

"Destroy" comes from the early days of the D forums where ideas posted
by enthusiastic people routinely get shot down ("destroyed") by people
pointing out fundamental flaws that they didn't think of.  Eventually it
became a local custom to invite participants to "destroy" after posting
one's idea, i.e., point out any flaws it may have so that we might know
whether it's worthwhile or not.

Now, where is that dtor... ;-)


T

-- 
Unix is my IDE. -- Justin Whear

Elronnd <elronnd elronnd.net> writes:

On Friday, 14 January 2022 at 23:28:44 UTC, Adam Ruppe wrote:
 Currently calling .destroy(class_object) fails the  nogc tests.

Practical Q: how many people are using classes without gc?  And 
how many of those people are actually using  nogc vs just not 
linking the gc in the first place?

evilrat <evilrat666 gmail.com> writes:

On Saturday, 15 January 2022 at 05:03:20 UTC, Elronnd wrote:
 On Friday, 14 January 2022 at 23:28:44 UTC, Adam Ruppe wrote:
 Currently calling .destroy(class_object) fails the  nogc tests.

 Practical Q: how many people are using classes without gc?  And 
 how many of those people are actually using  nogc vs just not 
 linking the gc in the first place?

I've used  nogc as simple diagnostic, shows where it can allocate 
inside hot paths, other than that - never.
But now there is also -vgc flag for this task which is less 
intrusive but also less "precise".

One can allocate classes without GC and handle its lifetime 
manually, there is actually whole class of tasks where one might 
need it (high-frequency trading, realtime software such as 
machinery controllers, game engines and games to some extent...).

There is also extern(C++) classes that can be used when you are 
limited to BetterC (for example WASM) or other low level software 
or even highly specific low level C++ interoperability where 
regular extern(C++) class just doesn't works (diamond problem, 
etc...).

Guillaume Piolat <first.last gmail.com> writes:

On Saturday, 15 January 2022 at 05:03:20 UTC, Elronnd wrote:
 On Friday, 14 January 2022 at 23:28:44 UTC, Adam Ruppe wrote:
 Currently calling .destroy(class_object) fails the  nogc tests.

 Practical Q: how many people are using classes without gc?  And 
 how many of those people are actually using  nogc vs just not 
 linking the gc in the first place?

We the annoying audio people, runtime can't be enabled reliably 
in shared libraries AFAIK for all platforms. -betterC doesn't 
have class instances.

Adam D Ruppe <destructionator gmail.com> writes:

On Saturday, 15 January 2022 at 10:39:47 UTC, Guillaume Piolat 
wrote:
 We the annoying audio people, runtime can't be enabled reliably 
 in shared libraries AFAIK for all platforms.

It can be done on dmd on Windows but is a pain. On all the other 
things, including ldc and gdc on Windows, it works well now.

Guillaume Piolat <first.last gmail.com> writes:

On Saturday, 15 January 2022 at 13:21:20 UTC, Adam D Ruppe wrote:
 On Saturday, 15 January 2022 at 10:39:47 UTC, Guillaume Piolat 
 wrote:
 We the annoying audio people, runtime can't be enabled 
 reliably in shared libraries AFAIK for all platforms.

 It can be done on dmd on Windows but is a pain. On all the 
 other things, including ldc and gdc on Windows, it works well 
 now.

IIRC: The remaining problem is on Linux, we absolutely want a 
static runtime (because distribution of a shared runtime is a 
pain for consumer products), but the static runtime isn't built 
with -fPIC.

Steven Schveighoffer <schveiguy gmail.com> writes:

On 1/15/22 12:03 AM, Elronnd wrote:
 On Friday, 14 January 2022 at 23:28:44 UTC, Adam Ruppe wrote:
 Currently calling .destroy(class_object) fails the  nogc tests.

 
 Practical Q: how many people are using classes without gc?  And how many 
 of those people are actually using  nogc vs just not linking the gc in 
 the first place?

Destructors can't allocate if running inside the GC. This makes them 
perfect candidates for  nogc.

So even if you use classes, and allocate them on the heap, running the 
destructors really should be tagged as  nogc (and who are we to say why 
anyone should or shouldn't be using the GC in any specific spot?)

-Steve

Stanislav Blinov <stanislav.blinov gmail.com> writes:

On Friday, 14 January 2022 at 23:28:44 UTC, Adam Ruppe wrote:
 ...

Oh, that's here:

https://issues.dlang.org/show_bug.cgi?id=15246

Adam D Ruppe <destructionator gmail.com> writes:

On Saturday, 15 January 2022 at 08:07:53 UTC, Stanislav Blinov 
wrote:
 https://issues.dlang.org/show_bug.cgi?id=15246

Yes, indeed. The current implementation is in part in compliance 
with the spec and non-compliance with another, then another part 
that makes it in compliance with another part of the spec and 
non-compliance with yet another part...

Then the combination of those two parts creates a new mix of 
compliance and non-compliance, where it emulates virtual 
destructors and gives reasonable attributes at the top level, but 
fails to enforce the attributes on the destructors themselves 
leading to the problem we have today.

BTW it is amazing to me to see obvious misconceptions persist for 
so many years. This ProtoObject nonsense needs to be put to bed 
so we can start actually fixing things.