@nogc destroy

Jan 14, 2022

Adam Ruppe

Jan 15, 2022

Jan 15, 2022

Jan 15, 2022

Jan 15, 2022

Jan 15, 2022

Jan 15, 2022

Jan 15, 2022

Jan 15, 2022

Jan 15, 2022

Jan 15, 2022

January 14, 2022

Posted by Adam Ruppe

Permalink

Adam Ruppe

Permalink

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!

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

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?

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

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.

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.

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.

Forums