Unofficial wish list status.(Jul 2008)

[Walter Bright]

Jason House wrote:
> Walter Bright Wrote:
> 
>> Jason House wrote:
>>> By far, my biggest complaint is that the const system makes only
>>> one of the following two methods compile.  It forces programmers
>>> to settle for using global variables to bypass const
>>> restrictions.  It also touches upon why the purity is required
>>> when doing multithreading.  I can't fully embrace const until it
>>> stops encouraging global variables and the gap between purity and
>>> const is reduced/eliminated.
>>> 
>>> =============
>> logFile log; class foo{ void bar() invariant{
>>> log.write("Hello World"); } } ============= class Foo{ logFile
>>> log; void bar() invariant{ log.write("Hello World"); } }
>>> =============
>> But the bar() function is not invariant,
> 
> That depends on which version of bar you're talking about.  The first
> bar conforms to the current D standard for invariance.  Everything in
> class foo remains untouched in the first example, and so bar is
> invariant.

True, but it is not pure. Pure functions cannot change global state.

>> nor can it be pure if it writes things to global state. I am not
>> sure why bar() needs to be pure, but it *cannot* be pure if it
>> changes either global state or the state of one of its arguments.
> 
> That's exactly right.  So what purpose is declaring bar as invariant
> serving?

I don't know why it needed to be marked as invariant (I didn't write it 
<g>).

> It's not supporting functional-style multithreading, but
> wasn't that the point for the const system?

It is one of the points of the const system. But the idea is not to just 
declare things invariant and magically they will work in functional 
style. The idea is that if you want to make something functional, the 
language will provide support for it if only in the form of telling you 
when something will not work in functional style. That appears to be the 
case with bar() - it cannot work in functional style.

> Since transitive const
> is already viral, it makes little sense to me that it shouldn't
> extend to static/global state.  That removes the temptation of
> programmers to use static/global state to circumvent the const
> system.  If that's problematic, then IMHO, something must be
> re-thought because it means people's use of D's const system will not
> support the functional-style multithreading because people are using
> it the wrong way.

The missing ingredient here is what the 'pure' modifier for functions 
provides. That is the ability to diagnose attempts to alter global state 
from within a function that is not supposed to do that. Invariant does 
not imply pure.

These concepts are not simple, but there is no way to support shared 
state in multithreaded programming without understanding those concepts. 
C++ the language has no concept of these things, and people get into 
endless trouble with it when misunderstanding things and screwing it up. 
The C++ language itself is of NO help at all. With D, the idea is to 
enable the language to help by moving things from convention to law. 
Completely ignoring the issues, like C++ does, is no solution.