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
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
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
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
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
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
