Perhaps we need to defer const for a while (3.0?)

[John Reimer]

Russell Lewis wrote:
> Originally, Walter argued that we didn't need const in D because it was 
> confusing and didn't solve the optimization problems that it was 
> intended to solve.
> 
> But then people made very good arguments about why we need const.  So 
> Walter brought const into the language, but with better semantics (than 
> C++).  Problem was, it was confusing to many people, and it didn't solve 
> all the problems that it was intended to solve.
> 
> Sound familiar?
> 
> Now we've gone through additional iterations (how many so far?) and we 
> still don't have it working quite right.  IMHO, this is the time to 
> recognize the *empirical* fact that as yet neither do we understand the 
> full requirements of what const should be trying to do nor do we have an 
> easily-understandable way to implement it.  I don't think that this is a 
> problem with the current design; it is a problem with our theoretical 
> grasp of the space.


It's actually a problem of molding an idea to fit a language that has 
already been mostly specified.


> 
> Walter, I'm not attacking you, truly.  I hold you in the highest regard, 
> and you have worked very hard for a very long time on const, and on D in 
> general.  But const isn't working.  My guess is that we need the PhD's 
> to write more papers on the theory of const before us mere mortals will 
> be able to use it in our practical languages.  A formal, mathematical 
> model for const, as it applies to imperative languages, with an 
> exhaustive examination of the various use cases (assignment, reference, 
> duplication, etc.) would be nice.
> 


I don't know about the need of a PhD, but a model of immutability is 
likely going to be closely tied with whole language design.  The 
difficulty remains in integrating const as an afterwords in D.  Other 
new languages may more accurately turn this very issue into a 
mathematical model by developing the whole language with const (or some 
other mode) as a basic premise. For example, erlang did this with 
concurrency, Smalltalk with Objects, Common Lisp with lists, etc.

D doesn't have that advantage; and, thus, the difficulty of fixing this 
perfectly will likely remain mostly elusive.  Plugging const into D is 
like tacking graphs together with multiple disconinuities amongst each.

Like it or not, D is somewhat stuck with the "kludge" model because of 
it's design decision to be flexible, as well a it's carryover from C/C++ 
ideology. The hope remains that most of these kludges can remain 
pseudo-consistent, simple, and attractive.   (Not all of D is a kludge. 
I'm just saying that some areas have had to be reworked to accommodate 
ideas that were not originally predicted, which is completely 
understandable for any invention).

> Maybe it's time to stop spinning our wheels here and start making 
> progress on other things.

I really don't know... I wouldn't say that wheels have been exactly 
spinning.  I'd like to remain somewhat optimistic and think that there 
have been two steps forward and one step back.  It's yet unclear, 
though.  At any rate, I doubt people will stop just because it's been 
suggested to stop. That's been tried before and tends to fail miserably. :D

-JJR