Re: Article: Why Const Sucks
On Thursday, 8 March 2018 at 15:13:09 UTC, Steven Schveighoffer
wrote:
On 3/8/18 9:58 AM, joe wrote:
On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis
wrote:
Here's something I wrote up on const:
/snip
May be not entirely related, but a little gotcha.
given:
interface XY {}
class Foo: XY {}
class Bar: XY {}
void doSomething(in XY sth)
{
auto foo = cast(Foo)sth; // error in @safe code
}
But the compiler doesn't emit a warning that const got cast
away in @system code.
Since @system is the default setting and casting const away is
by definition undefined behavior, there should be some
feedback.
If you cast away const in C++ you need to be explicit about it
by using const_cast, documents the intention rather than D's
swiss-army-cast.
This is a problem with the cast system, not const. ...
I figured. Sorry for off topic.
... D has one cast mechanism, and it's used to:
a) dynamic type cast
b) hook user-supplied opCast
c) enter undefined behavior by casting away const/immutable.
I really think we should have a separate mechanism for a and b,
as they are far less dangerous than c.
std.conv.to does this as well, ...
Thanks for pointing this out.
...but the language should have some safeguards against using
"safe casting" incorrectly.
-Steve
yes, that's what I was aiming for :)
This one got me because I assumed, with all the improved security
in place, D would never silently do such a thing...
Assumptions, right? ...the root of all evil. I should know
better. haha.
Anyways, thanks for the insight and have a nice Sunday.
Re: Article: Why Const Sucks
On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote:
Here's something I wrote up on const:
/snip
May be not entirely related, but a little gotcha.
given:
interface XY {}
class Foo: XY {}
class Bar: XY {}
void doSomething(in XY sth)
{
auto foo = cast(Foo)sth; // error in @safe code
}
But the compiler doesn't emit a warning that const got cast away
in @system code.
Since @system is the default setting and casting const away is by
definition undefined behavior, there should be some feedback.
If you cast away const in C++ you need to be explicit about it by
using const_cast, documents the intention rather than D's
swiss-army-cast.
Re: Article: Why Const Sucks
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 swy! writeln not const-y, no can do, swy! 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
