Unofficial wish list status.(Jul 2008)

[Jason House]

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.


> 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?  It's not supporting functional-style multithreading, but wasn't that the point for the const system?  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.