On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote:
Here's something I wrote up on const:
http://jmdavisprog.com/articles/why-const-sucks.html
I suppose that it's not exactly the most positive article, but
I feel that it's accurate.
- Jonathan M Davis
Interesting read and it explains some of the incomprehensible
error messages.
Basically you're saying we've got a strong const in D but
essentially the situation is much like in Java because the
general approach is don't use it ? Kind of ironic.
I made a Logger module a couple years back and I used const very
generously.
Then came the moment where the LogWriters actually had to do the
writing.
One would assume that a function called 'stdio.write' mutates
some state, but it sure as hell doesn't affect the state of my
logger.
DMD said: So soooowy! writeln not const-y, no can do, soooowy!
So I remove const. One function at a time and end up with a
module where basically no const remains.
But it doesn't stop there. Since logger isn't const anymore, it
now can't be used in any const functions. So more
de-const-ification happened...
Also, it's frustrating to have to get rid of const because
Object.toString uses some Outputwriter thing which is not const
and therefore transitively you can't have const anywhere else.
Kind of a disappointing experience.
As far as I'm concerned, it's not so much "don't use const; or,
it's not worth it" but more like "I would if I could but I can't
so I shan't".
I bother with const as much as possible but it's incredible
frustrating and I would argue the time lost to de-const-ify APIs
is easily equivalent to a code breaking change that would make
const more applicable.
Something possimpible. Like a compiler that doesn't purely make
decisions upon a const keyword, but one that can understand that
interacting with some random function with only "in" parameters
or objects, which aren't even interacting with,or are part of,
the object's internal state and are just passed through, can't
violate the const-ness of the object.
But there's likely much more to consider than that and I couldn't
ever dream of implementing such a thing..unfortunately
