Why do we have transitive const, again?

[Jonathan M Davis]

On Friday, September 23, 2011 19:58:41 Mehrdad wrote:
> On 9/23/2011 7:09 PM, Jonathan M Davis wrote:
> > Then the lack of logical const is really your issue, not the
> > transivity. Granted, logical const would be less of an issue if const
> > weren't transitive, but ultimately, it's the fact that there is no way
> > to alter a const variable without subverting the type system that's
> > your problem.
> 
> Yeah, so we both seem to agree that the *cause* of the problem
> (inability to have logical const, or whatever you want to call it, I
> don't really care what it's called) is the presence of transitive const.
> I'm not talking about the problem, but the cause.
> 
> > If you don't care about purity, it _is_ possible to have caching and
> > lazy loading, but it's a bit ugly IMHO.
> 
> Yeah, that's why I think we should remove the transitivity. Then this
> would be a non-issue.
> 
> > ...
> 
> No idea what you were saying since I don't know what "AA" stands for,
> sorry. :(

Associative array.

> > So, is the fact that D's const does not allow for any kind of caching
> > or lazy loading the only issue that you're really seeing with const
> > (beyond implementation issues)?
> 
> Actually, it IS an implementation issue, not a performance/optimization
> issue.
> i.e. this class reads from a terminal, and it's not like I can make it
> read at a different time, since doing so at the wrong time would cause
> it to deadlock. So I have to grab the input on the first fetch, and it's
> not like I'm doing this to optimize anything... the code simply _won't
> function_ if I don't do this.
> 
> > It _is_ an issue, and the transivity does make it worse, since more
> > stuff is const than would be otherwise, but are there other issues
> > beyond that?
> 
> See above. It's a real issue, not a performance issue.
> 
> > I think that it would be great if we could find a solution to lazy
> > loading and caching so that it works with const, but I fear that at
> > this point, that that is relegated to D3 unless someone can come up
> > with a very clever solution that is backwards compatible.
> 
> I guess that means D might not really catch on until D3? Problems like
> this come up often enough to make D kind of annoying to use...

Many, many people _never_ try and lazy load or cache variables like you're 
trying to do. So, there are many, many people that this will never affect. 
Obviously, it _will_ affect people but not enough that it would cripple D's 
chances of catching on. Also, since all you have to do to work around the 
issue is to not use const in this particular case (and there are already tons 
of programmers who never use const and have no interest in it), and you're 
fine, I don't see how this can be a showstopper for adopting the language. Yes, 
it's annoying, but there's a workaround which doesn't affect performance at 
all, and if something like this is all it takes for you to decide that you're 
not going to use a particular language, then it's going to be hard to get you 
to use _any_ language. They _all_ have issues of one sort or another, if 
nothing else because every language makes its own share of tradeoffs based on 
its goals. The question is whether the language as a whole meets your 
requirements enough better than another language, not whether one particular 
feature is a problem or not - though obviously a particular feature could be 
the straw that breaks the camel's back if there are a lot of issues.

- Jonathan M Davis