On Sunday, 28 May 2023 at 07:02:53 UTC, Walter Bright wrote:
> On 5/27/2023 6:40 PM, Steven Schveighoffer w
>> In any case, migrating `malloc` calls to `new` and ignoring `free` should still be fine in this case.
>
> That's how dmd used to operate, but people ran out of memory.

I never quite liked the reasoning that leaking is fine because its just a batch program.

I see teardown as an important part of a program. Relying on the OS to do it for you will likely come back to bite you at some point.

On Sunday, 28 May 2023 at 07:12:22 UTC, Sebastiaan Koppe wrote:
> On Sunday, 28 May 2023 at 07:02:53 UTC, Walter Bright wrote:
>> On 5/27/2023 6:40 PM, Steven Schveighoffer w
>>> In any case, migrating `malloc` calls to `new` and ignoring `free` should still be fine in this case.
>>
>> That's how dmd used to operate, but people ran out of memory.
>
> I never quite liked the reasoning that leaking is fine because its just a batch program.
>
> I see teardown as an important part of a program. Relying on the OS to do it for you will likely come back to bite you at some point.

It also encourages people to write code that doesn't pay attention to lifetimes or dependencies within the code (e.g. dmd was written with the assumption that you never have to free anything -> the code keeps references to stuff everywhere -> GC can't free it)

On Sunday, 28 May 2023 at 07:06:54 UTC, Walter Bright wrote:

> Autodecoding is a feature of the library, not the language. We've all agreed that Phobos v2 will not have it.

Some news on that point? The lasts info that I remember was Andrei trying to find a way to conflate sources between v1 and v2 (instead of copy/past sources), but there was a showstopper that I don't remember with templates or mixin or whatever ...

/P

On Sunday, 28 May 2023 at 07:12:22 UTC, Sebastiaan Koppe wrote:
>
> I never quite liked the reasoning that leaking is fine because its just a batch program.
>
> I see teardown as an important part of a program. Relying on the OS to do it for you will likely come back to bite you at some point.

+1

Not having deterministic teadown of resources is a bit unnerving. I was never a big fan of the undeterministic deconstructors in D compared to the more deterministic in C++.

Not solving lifetimes in CTFE is likely to limit its versatility. This also include proper freeing of resourced in CTFE. For example if you write to a file and do not close the file in CTFE, what happens?

On 5/28/2023 10:09 AM, IGotD- wrote:
> Not having deterministic teadown of resources is a bit unnerving. I was never a big fan of the undeterministic deconstructors in D compared to the more deterministic in C++.

Struct destructors in D are equally deterministic as in C++.

> Not solving lifetimes in CTFE is likely to limit its versatility. This also include proper freeing of resourced in CTFE.

A GC makes CTFE more versatile, not less.

> For example if you write to a file
> and do not close the file in CTFE, what happens?

CTFE (deliberately) does not allow access to the operating system, including file I/O. Jonathan Blow's Jai language does, for comparison.

On 5/28/2023 8:40 AM, Steven Schveighoffer wrote:
> So using the GC isn't good enough then?

It's good enough for CTFE :-)


>> Every time an allocation is made with the GC, the GC may run a collection cycle.
> During CTFE too? I mean CTFE allocates memory like crazy anyways (like for adding two integers), but I thought collections did not run *during* CTFE.

The GC may run a collection cycle anytime a GC allocation is done.


> I obviously could be wrong, but I thought the interpreter's data was self-contained, and when it was done, then it could become garbage.

I tried to do that at one point, and failed, after spending a couple weeks on it. It's not impossible, it's just that our CTFE implementation is a rat's nest and defies such improvements.

I did get a lot of the allocations done on the stack, which do go away when it returns. But not all.


> If malloc allocates GC memory, wouldn't the GC just take care of it?

Then you might as well just use the GC instead of malloc.

On 5/28/2023 12:11 PM, Basile B. wrote:
> I think CTFE memory is not gcmalloc'ed anymore, see dmd PR 10343, ["Start allocating CTFE memory in a separate Region"](https://github.com/dlang/dmd/pull/10343)

It still is not entirely successful.

On 5/28/2023 2:39 AM, Paolo Invernizzi wrote:
> Some news on that point?

The update is nobody has been willing to invest the time into it.