const

[eao197]

Walter Bright Wrote:

> 4. Here's the biggie. Points 1..3 are insignificant in comparison. The 
> future of programming will be multicore, multithreaded. Languages that 
> make it easy to program them will supplant languages that don't. 
> Transitive const is key to bringing D into this paradigm. The surge in 
> use of Haskell and Erlang is evidence of this coming trend (the killer 
> feature of those languages is they make it easy to do multiprogramming). 
> C++ cannot be retrofitted to supporting multiprogramming in a manner 
> that makes it accessible. D isn't there yet, but it will be, and 
> transitive const will be absolutely fundamental to making it work.

Ironically, the transitive const makes multithreading programming harder for me. Just imagine multithreaded messages passing framework which implements publisher-subscriber model. Subscribers work on different threads, so it is necessary to guarantee that message object will not been changed by anyone. A small illustration:

// Without const/invariant.
class LogChangedNotify {
  public Log newLog;
}

class GoodSubscriber : Subscriber {
  void onLogChange( LogChangedNotify msg ) {
    log = msg.newLog;
  }
  private Log log;
}

class BadSubscriber : Subscriber {
  void onLogChange( LogChangedNotify msg ) {
    msg.newLog = null;
  }
}

BadSubscriber easily can change contents of message even if BadSubscriber author doesn’t intend to do that. So in D 1.0 the best solution is duplicating each message for every subscriber (but it may be too expensive in the cases of big count of subscribers) or relying on convention that nobody changes message’s contents.

D 2.0 could improve the situation a lot: subscribers would receive messages via const (or even better via invariant) references:

class BadSubscriber : Subscriber {
  void onLogChange( invariant(LogChangedNotify) msg ) {
    msg.newLog = null; // Doesn’t compile!
  }
}

But transitive const doesn’t allow transfer of non-const information via const/invariant message objects:

class GoodSubscriber : Subscriber {
  void onLogChange( invariant(LogChangedNotify) msg ) {
    // Doesn’t compile because this.log is not invariant, but msg.newLog is.
    log = msg.newLog;
  }
  private Log log;
}

So in my multithreading experience there were a lot of situations where I needed a const object with references to non-const data inside. Because of that I think that sometimes transitivity of const is a barrier for a developer.

PS. I’m not a D programmer yet not because D has something or miss something as a language, but because I think that priority #1 should be support of stable release of language (e.g. D 1.0), not the development of D 2.0.