digitalmars.dip.development - First Draft: Placement New Expression
- Walter Bright (2/2) Oct 30 Based on a suggestion by Manu Evans:
- Richard (Rikki) Andrew Cattermole (25/26) Oct 30 I recommend that this includes allocator support.
- Richard (Rikki) Andrew Cattermole (2/5) Oct 30 Ugh s/paid/pain/
- Walter Bright (3/4) Nov 01 An allocator should be able to deliver a void[], I'm not seeing where
- Richard (Rikki) Andrew Cattermole (17/22) Nov 01 The specialized support is that the compiler will call ``allocate`` with...
- Walter Bright (4/5) Nov 01 Currently, there isn't a compile time solution for the allocated size of...
- Paul Backus (2/7) Nov 01 __traits(classInstanceSize, T) works at compile time.
- Walter Bright (2/3) Nov 01 Ehhxcellent!!
- ryuukk_ (4/8) Oct 31 Walter, you made -betterC, you are supposed to know there is no
- jmh530 (2/4) Oct 31 Can you add an example?
- Nick Treleaven (4/9) Oct 31 It would be good if any DIP that replaces `emplace` could avoid
- Paul Backus (4/16) Oct 31 Easiest way to do this is to allow using a `void[]` for all
- Paul Backus (2/4) Oct 31 Sounds great. No notes. 👍
- Richard (Rikki) Andrew Cattermole (11/11) Nov 01 After thinking about this a bit, this expression is going to have to be
- Richard (Rikki) Andrew Cattermole (13/28) Nov 01 Given this, I have to ask the question, what is the purpose of adding
- =?UTF-8?Q?S=C3=B6nke_Ludwig?= (3/7) Nov 02 Should probably mention the old "class allocators":
- Walter Bright (3/6) Nov 18 Yes. thanks!
- Walter Bright (2/2) Nov 10 Spinning up an implementation:
- Timon Gehr (3/7) Nov 10 Maybe `emplace` could be made into an intrinsic instead of changing the
- Walter Bright (2/4) Nov 18 It's an interesting idea. One difficulty is there are many variants of `...
Based on a suggestion by Manu Evans: https://github.com/WalterBright/documents/blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.md
Oct 30
I recommend that this includes allocator support. ```d struct Allocator { void[] allocate(size_t, TypeInfo ti=null); void deallocate(void[]); } ``` We would need a way to tie into deallocate + destroy. Say perhaps ``delete(allocator) thing;`` statement? This little bit of convenience would be a huge QoL improvement, as it'll calculate the size needed to be allocated for you (including for say arrays). This can be a bit of paid to do properly due to overflow.The size of the memory object of class Type can be retrieved with theexpression __traits(initSymbol, Type).length. ```d pragma(msg, __traits(initSymbol, Foo).length); struct Foo { int x; } ``` ``` onlineapp.d(1): Error: cannot determine the address of the initializer symbol during CTFE onlineapp.d(1): while evaluating `pragma(msg, Foo.length)` ``` We need a CTFE'able solution to this, for that argument to hold.
Oct 30
On 31/10/2024 7:33 PM, Richard (Rikki) Andrew Cattermole wrote:This little bit of convenience would be a huge QoL improvement, as it'll calculate the size needed to be allocated for you (including for say arrays). This can be a bit of paid to do properly due to overflow.Ugh s/paid/pain/
Oct 30
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.
Nov 01
On 02/11/2024 8:53 AM, Walter Bright wrote:On 10/30/2024 11:33 PM, Richard (Rikki) Andrew Cattermole wrote: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.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.
Nov 01
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. For CTFE, just use plain ordinary new.
Nov 01
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:__traits(classInstanceSize, T) works at compile time.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.
Nov 01
On 11/1/2024 1:02 PM, Paul Backus wrote:__traits(classInstanceSize, T) works at compile time.Ehhxcellent!!
Nov 01
On Thursday, 31 October 2024 at 06:23:24 UTC, Walter Bright wrote:Based on a suggestion by Manu Evans: https://github.com/WalterBright/documents/blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.mdIf one desires to use classes without the GC, such as in BetterC, it's just awkward to use emplace.Walter, you made -betterC, you are supposed to know there is no such thing as "TypeInfo", therefore no such thing as "class", it ain't -betterJava++ is it?
Oct 31
On Thursday, 31 October 2024 at 06:23:24 UTC, Walter Bright wrote:Based on a suggestion by Manu Evans: https://github.com/WalterBright/documents/blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.mdCan you add an example?
Oct 31
On Thursday, 31 October 2024 at 06:23:24 UTC, Walter Bright wrote:Based on a suggestion by Manu Evans: https://github.com/WalterBright/documents/blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.mdWith the placement new expression, operator new can initialize an object into any location. It replaces the functionality of core.lifetime.emplace.It would be good if any DIP that replaces `emplace` could avoid violation of immutable data in system code, or at least in safe: https://issues.dlang.org/show_bug.cgi?id=24795
Oct 31
On Thursday, 31 October 2024 at 18:17:56 UTC, Nick Treleaven wrote:On Thursday, 31 October 2024 at 06:23:24 UTC, Walter Bright wrote:Easiest way to do this is to allow using a `void[]` for all types, not just classes.Based on a suggestion by Manu Evans: https://github.com/WalterBright/documents/blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.mdWith the placement new expression, operator new can initialize an object into any location. It replaces the functionality of core.lifetime.emplace.It would be good if any DIP that replaces `emplace` could avoid violation of immutable data in system code, or at least in safe: https://issues.dlang.org/show_bug.cgi?id=24795
Oct 31
On Thursday, 31 October 2024 at 06:23:24 UTC, Walter Bright wrote:Based on a suggestion by Manu Evans: https://github.com/WalterBright/documents/blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.mdSounds great. No notes. 👍
Oct 31
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(...) ```
Nov 01
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[]); ```
Nov 01
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.mdShould probably mention the old "class allocators": https://dlang.org/deprecate.html#Class%20allocators%20and%20deallocators
Nov 02
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%20deallocatorsYes. thanks! https://github.com/WalterBright/documents/blob/master/placementnew.md
Nov 18
Spinning up an implementation: https://github.com/dlang/dmd/pull/17057
Nov 10
On 10/31/24 07:23, Walter Bright wrote:Based on a suggestion by Manu Evans: https://github.com/WalterBright/documents/ blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.mdMaybe `emplace` could be made into an intrinsic instead of changing the grammar? It would also implicitly improve existing code.
Nov 10
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`.
Nov 18