const

[Walter Bright]

Benji Smith wrote:
> I'd like to point out that we don't really know if it causes mistakes, 
> because no one has ever tried it.

True, but we do have experience where A means !A are juxtaposed with A 
means A, and it's pretty much always bad.


> At least they'd be the kind of mistakes that the compiler could catch.

It hurts my brain to constantly have to think twice about what a 
particular declaration means, since it will shift depending on the context.


> "Error: can't modify the value of a non-mutable argument, on line 235"
> 
> With the current implementation, if a programmer forgets to annotate an 
> argument as const, the compiler can't correct the error.

It can issue an error if the argument is const, but the parameter is 
mutable.


> The FAQ also says "It would be a huge break from past D practice, and 
> practice in C, C++, Jave, C#, etc."
> 
> But isn't the same thing true of transitive const? You yourself said 
> that no other language has ever implemented transitive const. So it's a 
> huge break from the past for all of us. It takes some brain-readjustment 
> to understand the mechanics of it, let alone the implications for 
> designing an API.

Let's look at another case. Gcc has inline assembler, and its arguments 
are exactly backwards from Digital Mars/Microsoft/Intel inline 
assembler. This screwing with my brain makes it extremely difficult for 
me to use it. It's not just a shift in meaning in a new direction, it's 
a *reversal* of meaning. It's like (well, not as bad as) exchanging the 
meaning of the * and + operators.


> (BTW, none of my comments so far have been about const transitivity, 
> because I don't understand it well enough to form an opinion.)
> 
> ...hmmmmmm... browsing through the rest of the FAQ...
> 
> I'm particularly interested in your "logical const" example, because it 
> demonstrates a memoization idiom that I use all over the place in my 
> everyday coding.
> 
> For example, I do a lot of work with vector-space representations of 
> data, and I have a bunch of classes for modeling vector spaces and 
> vectors within those spaces.
> 
> Each vector usually represents some sort of document, and the magnitude 
> in each dimension usually represents the term frequency (or, more 
> generically, a weight for whatever feature is modeled by the given 
> dimension). It's not uncommon for an individual vector to have hundreds 
> or thousands of dimensions.
> 
> In one of my projects, the full vector space had more than half a 
> million distinct dimensions, and the biggest vectors each projected into 
> ten or fifteen thousand of those dimensions.
> 
> With such a model, you can calculate the "information weight" of a 
> vector by taking its magnitude. Or you can calculate similarities 
> between two documents by taking the cosine of their vectors.
> 
> Vector cosine is calculated by dividing the vectors' dot products by the 
>  product of the vector magnitudes. And, since I often need to calculate 
> thousands of these vector cosines (to find a pair of documents with high 
> similarity), each vector object lazily calculates (and then memoizes) 
> its magnitude.
> 
> I can't remember the exact results, but when I implemented magnitude 
> memoization, my algorithms sped up by at least an order of magnitude.
> 
> On the one hand, the vector itself (once constructed) is const, becuase 
> I never add, remove, or alter the value of any dimension. But if a 
> vector's magnitude is never requested (either directly or through a 
> cosine calculation), then the magnitude is never calculated.
> 
> I'd be sunk without the availability of that kind of functionality. I 
> use it all over the place. (Especially for calculating object hash codes 
> (the majority of my code is in Java and C#)).
> 
> I suppose in D, I'd have to avoid declaring vectors as const. Which 
> would be a shame, because the basic data in the structure is never 
> modified after construction. The only thing that *ever* changes is those 
> values that are lazily evaluated and then memoized.

While you cannot use const for such a class, I don't see how not using 
const hurts it.