Second Draft: Placement New Expression

Richard (Rikki) Andrew Cattermole richard at cattermole.co.nz
Tue Nov 19 05:05:57 UTC 2024


This still includes typed expressions, which I have some concerns about.

We should not be condoning uninitialized memory as having a type. It can 
only cause problems for people. If we stick to ``void[]`` as the input, 
we can limit the source to ``@system`` code only.

No double-init bugs please.

The side benefit of this, is the the length is known. If not big enough, 
return null.

At the very least we should think about how to make a memory safety DFA 
with one layer of indirection support, so not just the variable being 
known to be initialized, but what the pointer points to also being 
initialized. That would make this a whole lot safer.

 > If one desires to use classes without the GC, such as in BetterC, 
it's just awkward to use emplace.

Not true, emplace is the easiest part of it as it becomes library code.

No reference counting on classes, lack of ability to mix -betterC with 
full D.

https://github.com/ldc-developers/ldc/issues/4779

These are the problems that need solving.

This is how I solved RC classes in -betterC, note that everything is 
templated (sigh), and that I have down casting working.

https://github.com/Project-Sidero/basic_memory/blob/main/source/sidero/base/allocators/classes.d#L183

 > The use of placement new is not allowed in @safe code.

Excellant!

Although I would prefer us to disallow casting to ``void*`` and 
``void[]`` also in ``@safe``.

Still too easy to introduce memory unsafe behaviors.

 > To allocate storage with an allocator function such as malloc(), a 
simple template can be used:

Why not support calling the allocator with the size needed?

```d
struct Allocator {
	void[] allocate(size_t);
}

Allocator a;

new (allocator) S;
new (malloc) S;
```

DONE.


More information about the dip.development mailing list