On Monday, 10 April 2017 at 04:49:34 UTC, Jack Stouffer wrote:
> On Monday, 10 April 2017 at 04:17:21 UTC, Swoorup Joshi wrote:
>> On Wednesday, 28 September 2016 at 20:50:28 UTC, Ali Çehreli wrote:
>>> https://www.reddit.com/r/programming/comments/54xnbg/herb_sutters_experimental_deferred_and_unordered/
>>>
>>> Ali
>>
>> Is it possible to have something similar as in library rather than GC in core language construct?
>
> Not without breaking changes.

Breaking, you mean the standard library? or including user codebases?

On Tuesday, 11 April 2017 at 07:02:19 UTC, Swoorup Joshi wrote:
> On Monday, 10 April 2017 at 04:49:34 UTC, Jack Stouffer wrote:
>> On Monday, 10 April 2017 at 04:17:21 UTC, Swoorup Joshi wrote:
>>> On Wednesday, 28 September 2016 at 20:50:28 UTC, Ali Çehreli wrote:
>>>> https://www.reddit.com/r/programming/comments/54xnbg/herb_sutters_experimental_deferred_and_unordered/
>>>>
>>>> Ali
>>>
>>> Is it possible to have something similar as in library rather than GC in core language construct?
>>
>> Not without breaking changes.
>
> Breaking, you mean the standard library? or including user codebases?

There's nothing stopping anyone from writing something similar in D. It just wouldn't make `new` not allocate on the GC heap.

Atila

On Tuesday, 11 April 2017 at 07:02:19 UTC, Swoorup Joshi wrote:
> Breaking, you mean the standard library? or including user codebases?

Taking the GC out of language constructs (e.g. ~=, AAs) would be a massive breaking change and would probably break the majority of D code in existence.

On Tuesday, 11 April 2017 at 16:16:03 UTC, Jack Stouffer wrote:
> On Tuesday, 11 April 2017 at 07:02:19 UTC, Swoorup Joshi wrote:
>> Breaking, you mean the standard library? or including user codebases?
>
> Taking the GC out of language constructs (e.g. ~=, AAs) would be a massive breaking change and would probably break the majority of D code in existence.

Is there a non-breaking way to do it that would increase the amount of flexibility while keeping the current behavior as a default? For instance, the equivalent of using std.experimental.allocator so that a user could switch between the default being GCAllocator or Mallocator, or something like that...

On Tuesday, 11 April 2017 at 16:50:20 UTC, jmh530 wrote:
> Is there a non-breaking way to do it that would increase the amount of flexibility while keeping the current behavior as a default? For instance, the equivalent of using std.experimental.allocator so that a user could switch between the default being GCAllocator or Mallocator, or something like that...

From what I understand, the plan has always been to start to integrate std.experimental.allocator into Phobos when it stabilizes. There are some questions though:

1. How is this going to be done? Do we have the functions in Phobos allocate with theAllocator? Or, do we pass in an allocator type via template parameter? Or, do we pass in an allocator instance via function parameter? Each solution has it's own pros and cons.

2. How do you make it @safe? For the GC allocator, you can make allocation @safe, but not deallocation. So do you special case GCAllocator in Phobos code to not call GCAllocator.deallocate() and just let the GC collect?

3. How will @safe ref-counting play in with this? Andrei has his sights set on putting all strings in their own ref-counted store in order to make them @safe @nogc. Is RC going to be it's own allocator?

I've never seen comprehensive plans or ideas about allocator integration. I've heard rumblings about a collections library that supposed to use it, but never seen anything.