inout(shared) as a thing?

[Steven Schveighoffer]

On 2/7/18 5:19 AM, Nicholas Wilson wrote:
> I was reading 
> https://github.com/rikkimax/stdc-signatures/blob/master/stdc/graphic/image.d#L54 
> as part of 
> https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md and it 
> struck me that the duplication of `IFoo` and `ISharedFoo` might be made 
> redundant `with inout(shared)` as `inout` (->`inout(const)`? so that one 
> can write `inout(shared,const)`. obviously no need to deprecate plain 
> inout) is to mutable/const/immutable.
> 
> I think this would work for "declarations" like 
> interfaces/signatures/contraints, I'm not so sure about implementations 
> as the acquisition of ownership needs to occur to take place in order to 
> avoid data races.
> 
> Maybe inout(shared=(T t){...}) where (T t){...} is a lamda (or some 
> other builtin) that ensures that t (or this) is owned by by the 
> executing thread. could also have inout(shared=synchronized), 
> inout(shared=synchronized(a)) where a is a variable in scope (e.g. 
> parameter, member,...), inout(shared=atomic) or some wrapper that 
> atomically loads t or this. Just throwing out ideas.
> 
> I don't think this would work on the return value of functions.
> 
> Thoughts? Worthy of a DIP?

I'm thinking it doesn't work.

Not because it wouldn't be sound from the standpoint of the type system, 
but because there is no "possibly shared" type constructor similar to 
const. If you are inside an inout(shared) function, how do you properly 
deal with the data? At the moment it's custom based on what your overall 
structure looks like. Sure, there are atomics for small shared data 
types, and at that level, you could conservatively just atomically load 
and store data. But what about shared aggregates? Those require locking 
at the right places, and there is no compiler-defined way to do it -- 
you have to write it yourself. There's just no way to do a "maybe 
shared" implementation for it.

-Steve