The following solution

http://static.rust-lang.org/doc/master/intro.html#owning-concurrency

is partially a good start...

but I believe it would be better to let the (D) compiler optimization stage figure out _automatically_ if it needs to make a copy of the variable `numbers` or not depending on whether `numbers` is used or not further down the body of `main`.

Are there currently any semantic passes in DMD that checks where reference data are read/written that could be utilized here?

Also Walter has talked about loads of data flow optimizations pending in DMD that for example automatically make new expressions immutable (and in turn shareable without locks) when possible.

> but I believe it would be better to let the (D) compiler optimization stage figure out _automatically_ if it needs to make a copy of the variable `numbers` or not depending on whether `numbers` is used or not further down the body of `main`.

I just realized that solving this in an elegant way (for reference types) would require some kind of new builtin property, say,

    r.isUnique

The compiler could, when possible, do this check at compile-time, and avoid any run-time (GC) or reference counting overheads done in isUnique.

I just found that this is highly related: http://wiki.dlang.org/DIP29

>> but I believe it would be better to let the (D) compiler optimization stage figure out _automatically_ if it needs to make a copy of the variable `numbers` or not depending on whether `numbers` is used or not further down the body of

I'm surprised that nobody has answered this discussion...

Isn't this an important question/possibility now that we soon have inference of uniqueness/immutability in DMD from Walters work?

Ping!

On Tuesday, 13 May 2014 at 11:04:18 UTC, Nordlöw wrote:
>>> but I believe it would be better to let the (D) compiler optimization stage figure out _automatically_ if it needs to make a copy of the variable `numbers` or not depending on whether `numbers` is used or not further down the body of
>
> I'm surprised that nobody has answered this discussion...
>
> Isn't this an important question/possibility now that we soon have inference of uniqueness/immutability in DMD from Walters work?
>
> Ping!

In general, anything that involves optimization must by definition not change program behavior. Copying vs. not copying usually has visible consequences, and therefore cannot be decided by the optimizer.

Furthermore, I think it is too fragile to (silently) base a decision about copying on what happens further down the program. You could too easily change something by accident.

The uniqueness changes in DMD are different, although I believe they are not yet properly documented. Uniqueness is only decided from the the expression that produced the value, but not from what further happens with the value.