The "no gc" crowd

[deadalnix]

On Wednesday, 9 October 2013 at 15:48:58 UTC, Sean Kelly wrote:
> On Oct 9, 2013, at 7:35 AM, Jacob Carlborg <doob at me.com> wrote:
>
>> On 2013-10-09 15:51, Sean Kelly wrote:
>> 
>>> Generally not, since even D's precise GC is partially 
>>> conservative.  It's also way more expensive than any cast 
>>> should be. For better or worse, I think being able to cast 
>>> data to shared means that we can't have thread-local pools. 
>>> Unless a new attribute were introduced like "local" that 
>>> couldn't ever be cast to shared, and that sounds like a 
>>> disaster.
>> 
>> Since casting breaks the type system to begin with and is an 
>> advanced feature. How about providing a separate function that 
>> moves the object? It will be up to the user to call the 
>> function.
>
> Okay so following that… it might be reasonable if the location 
> of data keyed off the attribute set at construction.  So "new 
> shared(X)" puts it in the shared pool.  Strings are a bit 
> trickier though, since there's no way to specify the locality 
> of the result of a string operation:
>
> shared string x = a ~ b ~ c;
>
> And I'm inclined to think that solving the issue for strings 
> actually gains us more than for classes in terms of performance.

The heap allocated part here is immutable. The slice itself is a 
value type.