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.
