On Friday, 1 November 2024 at 19:56:04 UTC, Walter Bright wrote:
> On 10/30/2024 11:33 PM, Richard (Rikki) Andrew Cattermole wrote:
>> We need a CTFE'able solution to this, for that argument to hold.
>
> Currently, there isn't a compile time solution for the allocated size of a class object.

__traits(classInstanceSize, T) works at compile time.

On 02/11/2024 8:53 AM, Walter Bright wrote:
> On 10/30/2024 11:33 PM, Richard (Rikki) Andrew Cattermole wrote:
>> I recommend that this includes allocator support.
> 
> An allocator should be able to deliver a void[], I'm not seeing where specialized support for it is needed.

The specialized support is that the compiler will call ``allocate`` with the appropriate size for you.

```d
T* t = new(allocator)T;
```

Is a whole lot better than:

```d
T* t = new(allocator.allocate(T.sizeof))T;
```

Especially with dynamic arrays, classes, structs all having different size calculations that you need to do.

Otherwise, I see no benefit when using allocators to use this syntax. Might as wrap it with the free-function ``make`` and ``makeArray`` that calls ``emplace``.

This will definitely come up again after implementation, it's too good of a QoL addition to not add.

On 11/1/2024 1:02 PM, Paul Backus wrote:
> __traits(classInstanceSize, T) works at compile time.

Ehhxcellent!!

After thinking about this a bit, this expression is going to have to be ``@system``.

Unfortunately this compiles:

```d
cast(void[])new int[1];
```

And so would this, without calling the destructor:

```d
T* t = new T(...);
new(t)T(...)
```

On 02/11/2024 6:47 PM, Richard (Rikki) Andrew Cattermole wrote:
> After thinking about this a bit, this expression is going to have to be ``@system``.
> 
> Unfortunately this compiles:
> 
> ```d
> cast(void[])new int[1];
> ```
> 
> And so would this, without calling the destructor:
> 
> ```d
> T* t = new T(...);
> new(t)T(...)
> ```

Given this, I have to ask the question, what is the purpose of adding this expression to the language if it cannot be ``@safe``?

For ``@system`` tasks like initialization it should be expected to have to import and call functions to do that action, as it should not occur in normal code.

Would it not be better to do a bit of design work on ``emplace`` instead to improve its usability so that it consistently has this form:

```d
size_t calculateSizeOf(T)();
size_t calculateSizeOf(T)(size_t count);
T emplace(T)(void[]);
```

Am 31.10.2024 um 07:23 schrieb Walter Bright:
> Based on a suggestion by Manu Evans:
> 
> https://github.com/WalterBright/documents/ blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.md

Should probably mention the old "class allocators":

https://dlang.org/deprecate.html#Class%20allocators%20and%20deallocators

Spinning up an implementation:

https://github.com/dlang/dmd/pull/17057

On 10/31/24 07:23, Walter Bright wrote:
> Based on a suggestion by Manu Evans:
> 
> https://github.com/WalterBright/documents/ blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.md

Maybe `emplace` could be made into an intrinsic instead of changing the grammar? It would also implicitly improve existing code.

On 11/10/2024 9:29 AM, Timon Gehr wrote:
> Maybe `emplace` could be made into an intrinsic instead of changing the grammar? It would also implicitly improve existing code.

It's an interesting idea. One difficulty is there are many variants of `emplace`.

On 11/2/2024 3:10 AM, Sönke Ludwig wrote:
> Should probably mention the old "class allocators":
> 
> https://dlang.org/deprecate.html#Class%20allocators%20and%20deallocators

Yes. thanks!

https://github.com/WalterBright/documents/blob/master/placementnew.md