Marco de Wild has penned a tutorial on D's const for the D blog. He gives an overview of the feature, how it differs from C++, and shows how he employed it in his mahjong game.

The blog:
https://dlang.org/blog/2019/03/25/using-const-to-enforce-design-decisions/

Reddit:
https://www.reddit.com/r/programming/comments/b5a9jm/using_const_in_d_to_enforce_design_decisions/

On Monday, 25 March 2019 at 13:00:07 UTC, Mike Parker wrote:
> Marco de Wild has penned a tutorial on D's const for the D blog. He gives an overview of the feature, how it differs from C++, and shows how he employed it in his mahjong game.
>
> The blog:
> https://dlang.org/blog/2019/03/25/using-const-to-enforce-design-decisions/
>
> Reddit:
> https://www.reddit.com/r/programming/comments/b5a9jm/using_const_in_d_to_enforce_design_decisions/

I guess obligatory http://jmdavisprog.com/articles/why-const-sucks.html

Would be nice to see the source code for this mahjong game as well.

On Monday, 25 March 2019 at 20:59:41 UTC, Rubn wrote:
> I guess obligatory http://jmdavisprog.com/articles/why-const-sucks.html

Good to read a different take on the subject. Jonathan uses a lot of arguments that I recognize (and adds a few that I didn't encounter in my project). I am a firm believer of using the type system and the compiler to aid development. Personally, I found it supplemental to the way I write code (with a strong DDD influence).

I've also tried to use pure, but (ironically) I found it harder to use. I think it's easier to understand when an object will be mutated or not than to predict whether there are side effects.

> Would be nice to see the source code for this mahjong game as well.

https://github.com/Zevenberge/Mahjong

I've been learning on the job, so there are a few quirks of earlier times that managed to avoid the blade of refactoring (including a case I discovered yesterday where mutable state could potentially leak). In general, I'm quite happy with it though.

The code for the example in the blog is, among others:
https://github.com/Zevenberge/Mahjong/blob/master/source/engine/flow/turn.d
We are looking at a part of the state machine modelling the various moments (phases) in a mahjong turn, more precisely the action decided by the turn player (e.g. discard or declare a win). A message is sent to the players (UI or AI). The message exposes a read-only view on all game data relevant for making a decision. Manipulations can only be done through predefined methods in the message (conceptually a return message). This means that the turn player can declare a win through a method in the message, but not restart the game, as that would require access to a mutable game object.

On 3/26/2019 12:57 AM, Marco de Wild wrote:
> I've also tried to use pure, but (ironically) I found it harder to use. I think it's easier to understand when an object will be mutated or not than to predict whether there are side effects.

Using pure is indeed hard. One has to make a change in how one thinks about programming to make good use of it, it can't just be schlepped on. But the results can be pretty cool.

Same with const.