On Saturday, 6 March 2021 at 20:21:41 UTC, Rumbu wrote:
>
> I took the article with a grain of salt when I saw the author claiming that finalisation of classes is a problem in all garbage collected languages. It seems that the author failed to update himself or - what's worse - wants to justify D failure in having deterministic class destruction by pointing to others.
>
> C# has IDisposable/using and Java has AutoCloseable as mechanisms for deterministic destruction.

Those C#/Java mechanisms are for deterministic destruction, akin to https://dlang.org/phobos/std_typecons.html#scoped. Mike warned only about indeterministic destructors -those that are only invoked when/if the object gets collected.

To be precise, class destructors are not any more problematic than struct desturctors if they are always called deterministically -see https://dlang.org/phobos/object.html#.destroy. But if the destructor needs to be called manually anyway, why should it be a destructor at all? It's probably better to put the finalizing in a normal function, or better yet to a destructor of a RAII struct.

Problems with GC-called destructors are not unique to D -see https://theartofmachinery.com/2018/12/05/gc_not_enough.html for a Ruby example.

> I remember when D had built-in allocator support and delete for deterministic destructors. Now they are deprecated and we have a library solution :)

I don't see why library solutions would be inherently inferior. What do we lose in case of deterministic destruction?

On Saturday, 6 March 2021 at 23:57:25 UTC, Dukc wrote:
>
> I don't see why library solutions would be inherently inferior. What do we lose in case of deterministic destruction?

First, library solutions show the lack of commitment from language creators. There is a big difference between "This is how to do X in D" and "This is one idea how to do X in D. Use this library. Or maybe not, probably there are other options". The latter makes programmers insecure regarding the *correct* approach when they want to do something.

Secondly, basic language constructs must be available in the core language not in a library, even if it's just druntime in this case. Putting them in the library makes the language unusable without that library.

On Saturday, 6 March 2021 at 20:45:00 UTC, Adam D. Ruppe wrote:
> On Saturday, 6 March 2021 at 20:21:41 UTC, Rumbu wrote:

> D *does* have deterministic class destruction. `scope Object o = new Object;`.

Thank you Adam for opening my eyes, I lived with the impression for years that scope initialization for classes is deprecated. In this case, the documentation must be clear that only "scope classes" are scheduled for deprecation, and this does not include "scope initialization".

Sorry, but when the chapter of scope classes starts with the note of deprecation, I assume that it is referring the entire chapter:

https://dlang.org/spec/class.html#auto

Yes, if you go further in deprecation details, you will find it written as a comment in a code example:

https://dlang.org/deprecate.html#scope%20as%20a%20type%20constraint


Believe it or not, a code comment is not the best place to put such important note.

On Saturday, 6 March 2021 at 21:12:51 UTC, Rumbu wrote:
> At least I didn't found any reference in the language specification except the one of scoped classes, which, of course, will be deprecated.

"For local declarations, scope implements the RAII (Resource Acquisition Is Initialization) protocol. This means that the destructor for an object is automatically called when the reference to it goes out of scope."

https://dlang.org/spec/attribute.html#scope

On Saturday, 6 March 2021 at 01:33:00 UTC, NonNull wrote:
>
> The article admits it is incomplete. But what can follow except workarounds if someone needs to get past this? And most won't work. This is not just a roadblock. It reveals the entropy inside D. The core of D is fatally flawed. D is not a language where system garbage is taken care of, both concretely and abstractly. The idea that we all system-program ourselves around these difficulties suggests both labor and depression.
>

I have alternative guidelines:

1. For class instances where destruction order is important (they transitively hold something that isn't only GC memory), use deterministic destruction. Can be with destroy(), scope, but not with a release() function.

2. If you fear those destructors to be called by the GC, avoid it with https://p0nce.github.io/d-idioms/#GC-proof-resource-class
If you accidentally rely on the GC for destruction, it will warn you.

That's it. It's super simple to have everything deterministic that way.

On Sunday, 7 March 2021 at 07:10:30 UTC, Rumbu wrote:
>
> First, library solutions show the lack of commitment from language creators. There is a big difference between "This is how to do X in D" and "This is one idea how to do X in D. Use this library. Or maybe not, probably there are other options". The latter makes programmers insecure regarding the *correct* approach when they want to do something.
>
> Secondly, basic language constructs must be available in the core language not in a library, even if it's just druntime in this case. Putting them in the library makes the language unusable without that library.

I'd agree with these if we were talking about a DUB package, but the standard library is called standard for a reason. It's one of the language maintainers (Atila) that also decides what will get to Phobos, so Phobos solutions are not outsourced solutions.

As for the language being unusable (or rather, less usable) without Phobos, I highly prefer it against more stuff being in the compiler. First off, it's not like you either use all of Phobos or no Phobos at all. Even a runtimeless device driver could easily use parts std.algorithm and std.range, since they are templated and do not depend on being linked to anything.

Second, if something does not work in Phobos, you can just avoid using it and work around the problem. Often it's even practical to give your workaround the same API as the Phobos equivalent. I know because I have worked with compiling to WASM. If that non-working feature were in the Druntime, you suddently get obscure errors, often from the linker, due to required DRuntime symbol missing. And if the compiler had the non-working feature, you'd have to patch and recompile the compiler before you can even start the real work!

On Sunday, 7 March 2021 at 12:11:26 UTC, Dukc wrote:
> On Sunday, 7 March 2021 at 07:10:30 UTC, Rumbu wrote:
>>
> As for the language being unusable (or rather, less usable) without Phobos, I highly prefer it against more stuff being in the compiler. First off, it's not like you either use all of Phobos or no Phobos at all. Even a runtimeless device driver could easily use parts std.algorithm and std.range, since they are templated and do not depend on being linked to anything.

Is anywhere a list of such features ?
I've seen many talk about them, but no concretic.

>
> Second, if something does not work in Phobos, you can just avoid using it and work around the problem. Often it's even practical to give your workaround the same API as the Phobos equivalent. I know because I have worked with compiling to WASM. If that non-working feature were in the Druntime, you suddently get obscure errors, often from the linker, due to required DRuntime symbol missing. And if the compiler had the non-working feature, you'd have to patch and recompile the compiler before you can even start the real work!

I think, druntime and phobos were divided a couple of years ago. So i can use druntime, but without phobos.

Hmm, translator jokes - fixes druntime as drunktime =)

On Saturday, 6 March 2021 at 03:07:32 UTC, Max Haughton wrote:
>
> I vaguely agree that the Garbage Collector as a global concept is dated, however: Be realistic - every programming language has guidelines (http://dev.stephendiehl.com/hask/ Even for Haskell they can be enormous) and dos and don'ts.

Modern garbage collection is region-based memory management with only two regions: One region where you can allocate for objects that will soon die, and one region for old objects, that if you leave garbage in, your application will pause because every object allocated forces an eventual Sweep phase, forcing the runtime to look at every single object, making memory allocation an O(N*G) operation, where G is the amount of old space garbage, and N is the amount of total objects. That easily becomes O(N^2).

(Yes, I'm aware of ZGC and Shenandoah, but most GCs don't work that way.)

On Saturday, 6 March 2021 at 20:21:41 UTC, Rumbu wrote:
> 
> C# has IDisposable/using and Java has AutoCloseable as mechanisms for deterministic destruction.

https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/implementing-dispose#dispose-and-disposebool

If that is what solved looks like, D fairs pretty good.

C# `using` is pretty nice, but it's implementation is still in every library that supports it and not part of the language.

```
scope(exit) obj.destroy();
```

This provides the same semantics as the using declaration.

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-8.0/using

Yes, D is different, but we shouldn't pretend other language solutions actually solved it.

On Sunday, 7 March 2021 at 20:08:20 UTC, Siemargl wrote:
> On Sunday, 7 March 2021 at 12:11:26 UTC, Dukc wrote:
>> Even a runtimeless device driver could easily use parts std.algorithm and std.range, since they are templated and do not depend on being linked to anything.
>
> Is anywhere a list of such features ?
> I've seen many talk about them, but no concretic.

No, just test yourself. In principle everything that does not need the GC, io, multitasking or the C standard library should be available in everywhere. But since that style of programming has less users and less testing, there is often the need to work around problems.

>
> I think, druntime and phobos were divided a couple of years ago. So i can use druntime, but without phobos.

Yes, you can. And it also works vice-versa - you can use many parts of Phobos with your own almost-nonexistently small Druntime. See https://github.com/skoppe/spasm for example.