On Wednesday, 9 October 2013 at 15:48:58 UTC, Sean Kelly wrote:
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.
The heap allocated part here is immutable. The slice itself is a
value type.
