On Oct 9, 2013, at 7:35 AM, Jacob Carlborg <[email protected]> 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.
