Thread overview
How do you properly use immutable on class members?
Mar 29, 2022
Fruitful Approach
Mar 29, 2022
H. S. Teoh
Mar 29, 2022
Ali Çehreli
Mar 29, 2022
Salih Dincer
Mar 29, 2022
Fruitful Approach
Mar 29, 2022
Ali Çehreli
March 29, 2022

I have immutable members:

immutable immutable(Prop)[] axioms which I can't initialize with Prop[], so I call this "immutable-poisoning" of the rest of my code. Can you provide a 10 line example of how to best work with immutable types, specifically immutable members, together with ctor, and accessor methods?

Also do I need to do immutable immutable(Prop)[] - that seems kind of wordy, especially when I have to duplicate that typing elsewhere. I could use an alias called Axioms I guess.

Every time I use const or immutable in C++ or D I end up failing with too many weird compilation errors, so I end up undoing all the places I inserted it. Should I just not use immutable or const except for on const method decoration where applicable?

There's no good tutorial on a realistic immutable example AFAIK.

March 29, 2022
On Tue, Mar 29, 2022 at 05:58:11PM +0000, Fruitful Approach via Digitalmars-d-learn wrote:
> I have immutable members:
> 
> `immutable immutable(Prop)[] axioms` which I can't initialize with Prop[], so I call this "immutable-poisoning" of the rest of my code. Can you provide a 10 line example of how to best work with immutable types, specifically immutable members, together with ctor, and accessor methods?

1) `immutable immutable(Prop)[]` is identical to `immutable(Prop[])`.
   Immutable is transitive. There is no need to spell it in such a
   verbose way.

2) Immutable fields can be initialized only in the ctor.

3) You *can* initialize immutable data with mutable data if it's a
   unique reference. Usually you get a unique reference by returning it
   from a pure function. For example:

	Prop[] makeProps() pure {
		return [ Prop.init ];
	}

	immutable(Prop[]) axioms = makeProps(); // OK

So in your case, what you could do is to initialize your immutable field in your ctor, like this:

	class MyClass {
		immutable(Prop[]) axioms;

		private Prop[] makeAxioms() pure { ... }

		this() {
			axioms = makeAxioms();
		}
	}


[...]
> Every time I use const or immutable in C++ or D I end up failing with too many weird compilation errors, so I end up undoing all the places I inserted it.  Should I just _not use_ immutable or const except for on `const` method decoration where applicable?

D's const/immutable and C++'s const are very different beasts.  D's const and immutable are transitive, meaning that if your outer reference is const, then everything it refers to will also be const (we call it "turtles all the way down").

Also, the way const interacts with mutable/immutable:

	         const
	         /   \
	(mutable)     immutable

Both mutable and immutable implicitly convert to const, but const does not implicitly convert to mutable/immutable (in general; there are exceptions like mutable -> immutable when it's a unique reference returned from a pure function, e.g. above).

Basically, const means "I'm not allowed to change this, but somebody else might". Immutable means "I'm not allowed to change this, neither is anybody else."

As a general principle, const should be used when you're on the receiving end of data that should not be changed (e.g., function parameters); immutable should be used when you're the owner of data that should not be change.


T

-- 
Holding a grudge is like drinking poison and hoping the other person dies. -- seen on the 'Net
March 29, 2022
On 3/29/22 11:59, H. S. Teoh wrote:

> As a general principle, const should be used when you're on the
> receiving end of data that should not be changed (e.g., function
> parameters)

Better yet, and as I know you know :), and as it comes up occasionally but I usually forget in my own code; 'in' is much better than 'const' on function parameters because it has super powers when compiled with -preview=in:

  https://dlang.org/spec/function.html#in-params

Ali

March 29, 2022
On 3/29/22 10:58, Fruitful Approach wrote:

> so I end up undoing all the places I inserted it.

That's what I do as well, which proves my 'const' object only hoped to be 'const'. I never say "I have to respect my decision from 10 minutes ago, so I must keep this object const." Nope! 'const' is replaced with 'auto' instantly. :)

'const' and 'immutable' on member variables are trouble because they make objects unassignable. (But you said 'class', so there is no such issue with them in D anyway.) But is that too bad? Is assignment overrated anyway? I don't know... :/

Ali

March 29, 2022

On Tuesday, 29 March 2022 at 19:26:51 UTC, Ali Çehreli wrote:

>

Better yet, and as I know you know :), and as it comes up occasionally but I usually forget in my own code; 'in' is much better than 'const' on function parameters because it has super powers when compiled with -preview=in:

Hello to everyone.

I think const is a redundant thing. Can you show me a direct side-effect that happens when we don't use const?

SDB@79

March 29, 2022
On Tuesday, 29 March 2022 at 18:59:41 UTC, H. S. Teoh wrote:
> On Tue, Mar 29, 2022 at 05:58:11PM +0000, Fruitful Approach via Digitalmars-d-learn wrote:
>> [...]
>
> 1) `immutable immutable(Prop)[]` is identical to `immutable(Prop[])`.
>    Immutable is transitive. There is no need to spell it in such a
>    verbose way.
>
> [...]

Thank you thank you thank you!  You've more than answered my concerns about using them.  So you're saying I should make my ctor parameters either const or `in`.  I will code some more and see if I can make this hurdle.