Why do we have transitive const, again?

[Jonathan M Davis]

On Sunday, September 25, 2011 03:07:22 Peter Alexander wrote:
> 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.

Well I suppose that it's a matter of semantics, but it's _not_ valid code, 
because D's const is not a logical const and does not support logical const in 
any way. So, the fact that you can't express valid code isn't really the 
issue, because you _can_ express valid code. What you want to do just isn't 
valid. The problem is the fact that there is no way in D to express the 
particular paradigm that you want to express - logical const.

> > 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?

Depends on how it's solved. I know that Andrei and Walter have a plan, but I 
don't know what it is. But if it's not a quality of implementation problem, 
then it's a quality of design problem, but regardless it's an issue that needs 
to (and will be) solved one way or another.

> 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.

No. They are _supposed_ to be const, and they're going to be const. The fact 
that they aren't const is crippling to const.

http://d.puremagic.com/issues/show_bug.cgi?id=1824

Now, once those functions are const, you should be able to override them with 
non-const versions, so as long as you're using a type which has a non-const 
version of the function you're trying to call, you should be able to have some 
level of caching and the like, but the fact those functions aren't const on 
Object is a big problem. It has been a long-standing complaint that those 
functions aren't const. And actually, we finally have pull requests which fix 
the problem, so there's a good chance that that bug will be fixed by the next 
release.

- Jonathan M Davis