On 09/13/2014 09:07 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> Wouldn't `const` be enough? AFAICS, `immutable` is mostly useful for
> shared data.

const prevents modification, but does not guarantee that no modification takes place elsewhere. I.e. it enables fewer program transformations.

And strong purity.

On Thursday, 11 September 2014 at 16:26:37 UTC, Marco Leise wrote:
> Shared/unshared may affect implementations that provide thread
> local GC. E.g. only shared data needs to be handled by a
> global stop the world GC. I'm not sure though.

Also a certain discipline is required to construct shared/immutable object from the start instead of casting from thread-local mutable. And then how to add an object to a shared collection?

//callable without lock
void add(shared Object) shared;
//allocated thread-local object
void add(Object);
//but unshared collection contains unshared objects
void add(shared Object);
//thread-local object again
void add(Object) shared;

?

On Saturday, 13 September 2014 at 19:20:51 UTC, Timon Gehr wrote:
> On 09/13/2014 09:07 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
>> Wouldn't `const` be enough? AFAICS, `immutable` is mostly useful for
>> shared data.
>
> const prevents modification, but does not guarantee that no modification takes place elsewhere. I.e. it enables fewer program transformations.

But as it is thread-local, is it really relevant (for optimization)? I can see two situations where it can potentially matter: pointer parameter aliasing, and calls to function/delegate calls that might modify a value referenced by a pointer.

In practice the latter is probably not so important for optimizations, because the compiler would most likely have a hard time caching a value across a function call because of register pressure, so a reload would be necessary anyway. I don't know about parameter aliasing, but I guess it only makes a difference in corner cases. In these cases, it's easy to forbid it by contract (as slice copying does).