On 5/20/2023 1:41 PM, Richard (Rikki) Andrew Cattermole wrote:
> It could just as easily work with malloc + free if somebody wanted to implement it.

Nobody has yet solved that problem.

On 27.05.23 20:26, Steven Schveighoffer wrote:
> On 5/27/23 1:09 AM, Walter Bright wrote:
>> On 5/20/2023 1:41 PM, Richard (Rikki) Andrew Cattermole wrote:
>>> It could just as easily work with malloc + free if somebody wanted to implement it.
>>
>> Nobody has yet solved that problem.
> 
> malloc -> new
> free -> noop
> 
> It's CTFE, nobody cares about memory leaks because the whole context will go away anyway.
> 
> We don't run the GC at CTFE either.
> 
> -Steve

```d
import core.stdc.stdlib;

enum p=malloc(16);
void main(){
    free(p);
}
```

On 5/27/2023 11:26 AM, Steven Schveighoffer wrote:
> It's CTFE, nobody cares about memory leaks

They do when it starts running very slow and/or runs out of memory


> because the whole context will go away anyway.

I've spent a lot of time trying to reduce its memory consumption. A lot of temps are now on the stack.


> We don't run the GC at CTFE either.

Yes, we do.

On 5/21/2023 4:04 PM, Theo wrote:
> I'm still bewildered why it's not self-evident to you as well.

I've been around D long enough to know well the enormous cost of trying to adapt C code to be usable from D. Much, much more than the cost of ImportC. If I'd realized this from the start, I would have done ImportC long ago.

On 5/27/2023 6:40 PM, Steven Schveighoffer wrote:
> On 5/27/23 5:21 PM, Walter Bright wrote:
>> On 5/27/2023 11:26 AM, Steven Schveighoffer wrote:
>>> It's CTFE, nobody cares about memory leaks
>>
>> They do when it starts running very slow and/or runs out of memory
> 
> But that's no different from today.

Yes, and people care about it.


>>> We don't run the GC at CTFE either.
>>
>> Yes, we do.
> 
> We do?

Every time an allocation is made with the GC, the GC may run a collection cycle.


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

On 5/19/2023 5:57 AM, monkyyy wrote:
> * Im on team stepouv, the only conceivable future of languages improving is the re-separation of data structures and algorithms that share a language wide interface, you get m*n solutions out of m+n(x3 cause overhead) lines of code. D has... 1 good data structure, the built-in dynamic array, aa's aren't implemented yet and wont be for the foreseeable future and I hate their interface anyway, every part of strings design needs to be replace, auto decoding is stupid as is defining a fundamental data type in one-liner to be clever. D needs data structures.

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


> * The average person writting the algorithm code must have gotten some weird ideas in their head, cause a x3 over head seems like an under estimation for the level of complexity in the std.
> 
> * There is a bunch of simple hacks to make ranges work, but you'd have to know them by heart as none are in the std, not even an identity map or `.map!(a=>a)`
> 
> * d3 should simplify the range interface, expand the data structure libs drastically, include range hacks, and lower their standards of correctness.

I don't really understand these proposals. Fleshing them out a bit more would be helpful.