A lot of the usefulness of the std.experimental.allocators module is lost because no other part of the stdlib actually ties into the functionality provided by it.

For example, the Array type defined in std.container relies on malloc() directly, so if you wanted to use a type to replace built-in arrays with a custom allocator, you'd need to implement your own container type.

Would it make sense to allow the std.container types to accept IAllocator instances, and to allow custom allocators? (Using Mallocator by default.)

On Thursday, 16 February 2017 at 15:37:52 UTC, Minty Fresh wrote:
> A lot of the usefulness of the std.experimental.allocators module is lost because no other part of the stdlib actually ties into the functionality provided by it.

The current rule of the standard library is that stuff outside of experimental is not allowed to use experimental, because, well, it's experimental. It's likely to break.

> For example, the Array type defined in std.container relies on malloc() directly, so if you wanted to use a type to replace built-in arrays with a custom allocator, you'd need to implement your own container type.
>
> Would it make sense to allow the std.container types to accept IAllocator instances, and to allow custom allocators? (Using Mallocator by default.)

The current std.containers design was not designed with allocators in mind. The current plan is

1. DIP1000, which adds safety checks for escape analysis to the language, must be completely implemented in order to have @safe containers
2. A new containers design will be submitted to std.experimental to eventually replace the current one

In the mean time you can always use https://code.dlang.org/packages/emsi_containers

On Thursday, 16 February 2017 at 15:48:44 UTC, Jack Stouffer wrote:
> On Thursday, 16 February 2017 at 15:37:52 UTC, Minty Fresh wrote:
>> A lot of the usefulness of the std.experimental.allocators module is lost because no other part of the stdlib actually ties into the functionality provided by it.
>
> The current rule of the standard library is that stuff outside of experimental is not allowed to use experimental, because, well, it's experimental. It's likely to break.

Yep, for reference please see this thread: http://forum.dlang.org/post/hxwadyrnvzvutrdcgsdp@forum.dlang.org

tld;dr: Current blockers are:
- no CTFE support
- dependent on druntime

On Thursday, 16 February 2017 at 15:37:52 UTC, Minty Fresh wrote:
> A lot of the usefulness of the std.experimental.allocators module is lost because no other part of the stdlib actually ties into the functionality provided by it.
>
> For example, the Array type defined in std.container relies on malloc() directly, so if you wanted to use a type to replace built-in arrays with a custom allocator, you'd need to implement your own container type.
>
> Would it make sense to allow the std.container types to accept IAllocator instances, and to allow custom allocators? (Using Mallocator by default.)

Appender also, although there some WIP for a complete @nogc version (which I'd prefer to be based on allocators too, but well not possible b/c of the reasons mentioned above).

On Thursday, 16 February 2017 at 15:48:44 UTC, Jack Stouffer wrote:
> The current std.containers design was not designed with allocators in mind. The current plan is
>
> 1. DIP1000, which adds safety checks for escape analysis to the language, must be completely implemented in order to have @safe containers
> 2. A new containers design will be submitted to std.experimental to eventually replace the current one

This is very useful information. Is there a thread or document describing this further? I'm not looking for hard decisions. Just that it's useful to have bigger picture view of what is on the horizon. If there's nothing readily available, perhaps a talk at DConf?

--Jon

On Friday, 17 February 2017 at 03:05:04 UTC, Jon Degenhardt wrote:
> This is very useful information. Is there a thread or document describing this further? I'm not looking for hard decisions. Just that it's useful to have bigger picture view of what is on the horizon. If there's nothing readily available, perhaps a talk at DConf?
>
> --Jon

This is based on conversations I've had with Andrei and Walter on here and on Github.

There was a bunch of threads here about six months ago by Andrei talking about the different problems he was running into when trying to implement @safe and @nogc containers. One of the conclusions was that ref counting was going to have to be a nessesary component of the solution. This led to DIP1000 because of Andrei's conclusion that "Safe reference counting cannot be implemented as a library" https://forum.dlang.org/post/n0nnu0$1tth$1@digitalmars.com.

Also, there's the vision document, which lays out some goals but does not talk about containers: https://wiki.dlang.org/Vision/2017H1

On Friday, 17 February 2017 at 04:13:06 UTC, Jack Stouffer wrote:
> This is based on conversations I've had with Andrei and Walter on here and on Github.
>
> There was a bunch of threads here about six months ago by Andrei talking about the different problems he was running into when trying to implement @safe and @nogc containers. One of the conclusions was that ref counting was going to have to be a nessesary component of the solution. This led to DIP1000 because of Andrei's conclusion that "Safe reference counting cannot be implemented as a library" https://forum.dlang.org/post/n0nnu0$1tth$1@digitalmars.com.
>
> Also, there's the vision document, which lays out some goals but does not talk about containers: https://wiki.dlang.org/Vision/2017H1

Excellent, thanks for sharing this.  --Jon