www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How do you properly use immutable on class members?

reply Fruitful Approach <fruitfulapproach gmail.com> writes:
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.
Mar 29 2022
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Mar 29 2022
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Mar 29 2022
parent Salih Dincer <salihdb hotmail.com> writes:
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
Mar 29 2022
prev sibling parent Fruitful Approach <fruitfulapproach gmail.com> writes:
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.
Mar 29 2022
prev sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Mar 29 2022