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

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

My biggest issues with const are, as you wrote, ranges and postBlit. I still use `const` everywhere unless I can't.

I used to use `immutable`, but gradually came around to only using it if I have to send data to another thread, otherwise it's too much of a hassle.

Atila

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

Brilliant article, Johathan! I feel the same...

Just a semantic note, it is "straitjacket". "straight" is like a non-wiggly line. "strait" means narrow or constricted. Thus, the straitjacket is a jacket that constricts your movement.

Of course, using "straight" is such a common mistake it has become generally accepted... but still, I like being precise with my words.

On Monday, March 05, 2018 11:38:05 Atila Neves via Digitalmars-d-announce wrote:
> I used to use `immutable`, but gradually came around to only using it if I have to send data to another thread, otherwise it's too much of a hassle.

Aside from the whole std.concurrency situation, I generally use immutable in the places where the semantics are the same as const, so it doesn't generally cause a problem for me. I just prefer immutable in the cases where it and const are the same, because immutable clearly indicates that the value never changes, so immutable more closely fits the idea even if const happens to mean that in that particular case. I agree that using immutable where you have to do stuff like design objects in a particular way in order to make immutable work is generally too much of a pain to be worth it, but at least in those cases, the data can then be shared across threads, and it's data that doesn't need mutable backdoors, because it only makes sense to use immutable in that fashion when the object is really designed to never change state.

I think that the only time that I've programmed heavily in a way that involves immutability everywhere is when I programmed in Haskell, and that combined with the fact that Haskell is lazy and completely functional such that you can't use imperative idioms anywhere made it so that each line of Haskell code took me more time to write than is the case with any other language I've used (except maybe batch, because of how insanely error-prone it is). I think that I'm a better programmer for it, but I'd hate to program that way normally, and using immutable all over the place would head too heavily in that direction - though at least D, unlike Haskell, is a multi-paradigm language and allows you to choose to use a particular idiom when you think it makes the most sense instead of forcing it everywhere.

- Jonathan M Davis

On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote:
> Here's something I wrote up on const:

Excellent read! I enjoyed the history of proposed solutions.

I've run into the trouble with annotated opEquals in classes several times. I believe an empty/nonexistant Object class is the correct solution, together with templates. If it breaks tricky opEquals-overriding usercode, then so be it. The const trouble is merely a symptom here, the real problem is Object.

In structs, all const members feel alien, they preventing all copying. This seems far harder to solve.

-- Simon

On Monday, March 05, 2018 13:48:23 Adam D. Ruppe via Digitalmars-d-announce wrote:
> Just a semantic note, it is "straitjacket". "straight" is like a non-wiggly line. "strait" means narrow or constricted. Thus, the straitjacket is a jacket that constricts your movement.
>
> Of course, using "straight" is such a common mistake it has become generally accepted... but still, I like being precise with my words.

Thanks for the correction. I probably knew at some point, but it's not a word that I use often, and I didn't even think about looking it up. Now, I'm more likely to remember in the future.

- Jonathan M Davis

On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote:
> Here's something I wrote up on const:


So as to the  main thrust, I generally agree. In fact, I think const is almost useless even if you want to use it fully: you said immutable is better in many places, and yes, but in addition to that, inout is better than const in most the remaining cases.

Constructing a const variable? Almost completely useless - immutable is better in almost all (if not actually all) cases. Referencing function parameters? inout is better in all cases except just plain input. If there's any part of it being returned - as is the case on most member methods to me at least - inout is flat-out better.

And then, of course, like you said "don't use it" is the solution to most of the const system's flaws anyway.... which seems to be the case with a lot of D's add-on qualifiers.

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

Great read for a Monday.

On Monday, March 05, 2018 13:53:21 SimonN via Digitalmars-d-announce wrote:
> On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote:
> > Here's something I wrote up on const:
> Excellent read! I enjoyed the history of proposed solutions.
>
> I've run into the trouble with annotated opEquals in classes several times. I believe an empty/nonexistant Object class is the correct solution, together with templates. If it breaks tricky opEquals-overriding usercode, then so be it. The const trouble is merely a symptom here, the real problem is Object.

Yes, the fact that those functions are on Object is a serious problem that affects more than const, but part of the reason for explaining that particular issue was to show how the use of const - or the lack thereof - on a member function can have serious consequences for a class hierarchy. It's by far the worst in the case of Object, because it affects _all_ classes in D, but any time that someone designs a class in D that is intendend to then have other classes derived from it, the same choices pop up; the consequences are just then on a smaller scale.

> In structs, all const members feel alien, they preventing all copying. This seems far harder to solve.

Yeah. I don't know what we do about that. In general, I think that it makes by far the most sense for value types to not be inherently const (even in part), so I'm not all that worried about the problems that stem from making a particular member variable const. But the fact that you then can't use a postblit constructor with a const object - even if nothing in the object is const unless the entire object is const - is definitely a problem.

IIRC, Walter's take on it was that it was bad design for objects to deep-copy like that and that it was just better to use stuff like COW, in which case, postblit constructors aren't generally needed. And as such, he's a lot less worried about the problem than otherwise might be the case. I agree that it's frequently problematic for copying to be expensive in that manner, but it's also sometimes very useful. I expect that a good, solid DIP on the subject would be accepted in spite of the fact that Walter isn't big on postblit constructors, but first, someone has to come up with such a DIP, and that's not even vaguely easy - especially if the answer doesn't involve adding a copy constructor to the language (which I would guess would be rejected due the extra complexity that it would add to the language, but I don't know). Either way, right now, it's just one more thing on the list of things that makes it difficult enough to use const in D that many of us use it fairly minimally.

- Jonathan M Davis