Missing const feature? Having a thread own the read/write privilege

[Jason House]

I expect this to be the last thing people want to hear when they already 
want to reduce the complexity of the const system...

If I understand things correctly, the big difference between const and 
invariant function parameters is that one allows the compiler to assume 
the variable won't get modified, and the other won't.  Both disallow the 
function from modifying it.  Most of the time, people say const is a 
read-only view of data that could be modified elsewhere.

The docs also say that implicit casts to invariant are not allowed, but 
data can be cast to invariant.  I probably don't have to convince most 
that cast can be a dangerous tool, and the normal const/invariant 
functionality shouldn't have to use it.

For single-threaded applications, I believe an implicit cast to _scope_ 
invariant is ok and *should* be allowed implicitly.  If I call a 
function, it's guaranteed that the variable won't get modified by 
anything else while the function is executing.

For multi-threaded applications, it becomes trickier.  I believe that an 
acceptable restriction would be that variables will only get modified by 
a specific thread.  If this is done, all other threads would treat the 
data as const (a read only view).

Can all variables in local function scope be treated as single-threaded 
with the current thread having the only write privileges?  While I bet 
someone can come up with a case, I'd argue that the default behavior 
should be that only the thread running the function should have write 
privileges.

Global variables likely can't assume that only a specific thread will 
modify them.

I have not thought of how to implement this.  I only thought of it 
yesterday and haven't tried to work it out in greater detail.  I'm going 
on travel for the next few days and probably won't be participating in 
the news group.  I wanted to get out the thought while the list was 
buzzing about const, invariant, etc...