Thread overview
Heads-up: upcoming instabilities in std.experimental.allocator, and what to do
Nov 30
Radu
Dec 01
Seb
Dec 01
Kagamin
November 30
Hi all,


Eduard, Alexandru Jercaianu and I are working on improving allocators' design and implementation. This entails a few breaking changes.

In order to make matters easier for code using allocators, Sebastian Wilzbach created a dub package freezing the existing API: http://code.dlang.org/packages/stdx-allocator. Please use that until we work the kinks out of allocators - great things are coming! - and after that feel free to upgrade code to use the new and improved allocators.

One rather disruptive piece we're working on is converting IAllocator from an interface to a reference counted structs (that in turn uses an interface internally). This is so there is deterministic control of how many users a given allocator has, so it can be destroyed deterministically.

Another possible work item was raised by https://github.com/dlang/phobos/pull/5879. Currently, allocators traffic in void[]. When I first designed allocators, I considered using ubyte[] instead. Using void[] is somewhat closer to the intent of allocators - that memory is meant to be used for storing anything. However, using void[] makes it difficult to express the fact that allocate() is a safe function for virtual all allocators. So we may switch to ubyte[] to express that at the lowest level we're trafficking chunks of octets. This is not a big design change, but it's bound to break code.


Thanks,

Andrei
November 30
On Thursday, 30 November 2017 at 19:01:02 UTC, Andrei Alexandrescu wrote:
> Hi all,
>
>
> Eduard, Alexandru Jercaianu and I are working on improving allocators' design and implementation. This entails a few breaking changes.
>
> [...]

Sounds good!

Please consider -betterC on your refactoring. Would be awesome to have a core allocators package working under betterC flag, meaning no D runtime deps.
December 01
On Thursday, 30 November 2017 at 19:01:02 UTC, Andrei Alexandrescu wrote:
> Hi all,
>
>
> Eduard, Alexandru Jercaianu and I are working on improving allocators' design and implementation. This entails a few breaking changes.
>
> In order to make matters easier for code using allocators, Sebastian Wilzbach created a dub package freezing the existing API: http://code.dlang.org/packages/stdx-allocator. Please use that until we work the kinks out of allocators - great things are coming! - and after that feel free to upgrade code to use the new and improved allocators.

I just pushed a couple of fixes [1] for older Phobos versions and stdx-allocator now works down until 2.072.2.
If someone needs an older Phobos version to work with stdx-allocator, please let me know.
Also switching to stdx-allocator is rather easy, e.g.:

```
sed -i "s/std[.]experimental/stdx/g" **/*.d
```

[1] https://github.com/wilzbach/stdx-allocator/commit/d06e4f2bae2eee5d380d145221ecb9cab04c90d7
December 01
On Thursday, 30 November 2017 at 19:01:02 UTC, Andrei Alexandrescu wrote:
> Currently, allocators traffic in void[]. When I first designed allocators, I considered using ubyte[] instead.

I experimented with using byte[] for opaque buffers, because byte is signed, one can't parse byte[] content in a meaningful way, and should cast to ubyte[] first, so byte[] is practically opaque (if you're careful).

> However, using void[] makes it difficult to express the fact that allocate() is a safe function for virtual all allocators.

Safe code should only use typed allocation (make) and never see underlying implementation.
December 01
On 2017-11-30 20:01, Andrei Alexandrescu wrote:
> Hi all,
> 
> 
> Eduard, Alexandru Jercaianu and I are working on improving allocators' design and implementation. This entails a few breaking changes.

It would be nice if the API and the GCAllocator were CTFE-able. This would allow functions that take allocators as parameters to be CTFE-able if you pass in the GCAllocator which doesn't work today.

-- 
/Jacob Carlborg
December 01
On Thursday, 30 November 2017 at 19:01:02 UTC, Andrei Alexandrescu wrote:
> Another possible work item was raised by https://github.com/dlang/phobos/pull/5879. Currently, allocators traffic in void[]. When I first designed allocators, I considered using ubyte[] instead. Using void[] is somewhat closer to the intent of allocators - that memory is meant to be used for storing anything. However, using void[] makes it difficult to express the fact that allocate() is a safe function for virtual all allocators. So we may switch to ubyte[] to express that at the lowest level we're trafficking chunks of octets. This is not a big design change, but it's bound to break code.

That argument should also apply to e.g. std.file.read.