Why do we have transitive const, again?

[Peter Alexander]

On 25/09/11 12:29 AM, Jonathan M Davis wrote:
> On Saturday, September 24, 2011 16:08:04 Walter Bright wrote:
>> On 9/22/2011 10:36 AM, Peter Alexander wrote:
>>> It's mostly for concurrent programming.
>>
>> It's also for:
>>
>> 2. purity
>> 3. support for true functional programming
>> 4. implicit&  enforcable documentation on what a function may do with its
>> parameters 5. better isolation and encapsulation of specific areas in a
>> program
>
> I use it for _way_ more than concurrent programming. In fact, I use it pretty
> much the exact same what that I do in C++. The difference is that you can't do
> any kind of caching or lazy loading of member variables or member function
> return values, but I _rarely_ do that anyway, so for what I do, it isn't an
> impedement at all. I think that Peter's take on it stems from the fact that
> he's work in a gaming enviroment where he cares a lot more about stuff like
> lazy loading and caching, because he needs them for performance. I would say
> thought that most domains don't need that. Some obviously do, and it would be
> nice to have with const, but when you actually care about stuff like
> __restrict, you're in a _very_ different world from your average programmer.

Lazy loading isn't usually for performance. Lazy loading/evaluation has 
very different semantics to eager evaluation (see 
http://www.haskell.org/haskellwiki/Lazy_vs._non-strict). There are many 
non-performance uses for it. Same goes for caching.

In any case, I'm all for catering to average users (whoever they are for 
D, most of the active users of D I see are game developers, or similar 
-- e.g. the PSPemu guy -- but maybe I have a skewed perspective), the 
problem I have is if the type system literally prevents me from 
expressing what I know to be valid code, with no legal escapes.


> The biggest roadblocks that I've run into with const stem from quality of
> implementation issues, which makes it so that const is unusable in a number of
> cases where it should be (e.g. this(this) not working with const and the fact
> that object isn't const-correct). So, I can't use it as much as I would like,
> but I use it a lot.

Heading off on a tangent here, but isn't the const this(this) problem a 
language problem rather than a QoI problem?

Also, what's wrong with const-correctness on Object? All its methods are 
non-const as they should be. If you made, for example, toHash() const 
then you wouldn't be able to cache the hash, and that's *definitely* 
something people will want to do in many situations. Same goes for 
toString and opCmp/opEquals.