www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - const or immutable?

reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
Please excuse this thread here, which I know belongs more to the Learn 
forum but I am interested in the opinions of experts here who do not 
frequent that forum.

tl;dr Do you use 'const' or 'immutable' by-default for parameters and 
for local data?

Long version:

It was simpler in C++: We would make everything 'const' as much as 
possible. Unfortunately, that doesn't work in D for at least two reasons:

1) There is 'immutable' as well

2) There is no head-const (i.e. no 'const' pointer to mutable data; i.e. 
"turtles all the way down")

Further complications:

- Reference semantics versus copy semantics; by type (e.g. slices), by 
the 'ref' keyword, by a member of a struct that has reference semanticts 
(struct is by-copy; but a member may not be), etc.

- It is said that 'immutable' is a stronger type of const, which at 
first sounds great because if 'const' is good, 'immutable' should be 
even better, right? Unfortunately, we can't make everything 'immutable' 
because 'const' and 'immutable' have very different meanings at least in 
parameter lists.

- Parameters versus local data.

I am seeking simple guidelines like C++'s "make everything const."

Let's start with what I like as descriptions about parameters:

1) 'const' parameter is "welcoming" because it can work with mutable, 
'const', and 'immutable'. It (sometimes) means "I am not going to mutate 
your data."

2) 'immutable' parameter is "selective" because it can work only with 
'immutable'. It means "I require immutable data."

But it's not that simple because a 'const' parameter may be a copy of 
the argument, in which case, it means "I will not mutate *my* data." 
This is actually weird because we are leaking an implementation detail 
here: Why would the caller care whether we mutate our paramener or not?

// Silly 'const':
void foo(const int i) {
   // ...
}

But of course it matters if the type has indirections (e.g. a member is 
a reference to some other data).

Aside: If 'const' is welcoming, why do we type 'string' for string 
parameters when we don't actually *require* immutable:

// Unenecassary 'immutable' but I do this everywhere.
void printFirstChar(string s) {
   write(s.front);
}

It should have better been const:

void printFirstChar(const char[] s) {
   write(s.front);
}

But wait! It works above only because 'front' happened to work there. 
The problem is, 's' is not an input range; and that may matter elsewhere:

   static assert(isInputRange!(typeof(s)));  // Fails. :(

So only the elements of the string should be 'const':

void printFirstChar(const(char)[] s) {
   write(s.front);
   static assert(isInputRange!(typeof(s)));  // Passes.
}

(Granted, why is it 'const' anyway? Shouldn't printFirstChar be a 
function template? Yes, it should.)

So, what are your guidelines here?

More important to me: How do you define your local data that should not 
be mutated?

   const     c = SomeStruct();
   immutable i = SomeStruct();

In this case, 'const' is not "welcoming" nor 'immutable' is "selective" 
because these are not parameters; so, the keywords have a different 
meaning here: With local data, they both mean "do not mutate". Is 
'immutable' better here because we may pass that data to an 
immutable-requiring function? Perhaps we should learn from string and 
make it really 'immutable'? But it's not the same because here 
'immutable' applies to the whole struct whereas 'string's immutability 
is only with its elements. There! Not simple! :)

Or, should 'immutable' be preferable here because it's implicitly 
shared, which may be useful in the future?

Are there simple guidelines around this topic? Please? :)

Personally, I generally ignore 'immutable' (except, implicitly in 
'string') both for parameters and local data.

Thank you,
Ali
Sep 22
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Wednesday, 22 September 2021 at 20:06:59 UTC, Ali Çehreli 
wrote:
 tl;dr Do you use 'const' or 'immutable' by-default for 
 parameters and for local data?
well i often ignore it but `const` (or often better yet, `inout` if there's any relation to a member of yours or if you return it) is better on function arguments, and `immutable` is better on internal members. The exception is when you are storing something from someone else, where immutable params might be more important. But if you are looking and not touching, const or `in` is good.
 Aside: If 'const' is welcoming, why do we type 'string' for 
 string parameters when we don't actually *require* immutable:
Unfortunate naming here... the convenient name encourages its use but it is indeed often suboptimal.
Sep 22
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 9/22/21 1:17 PM, Adam D Ruppe wrote:
 On Wednesday, 22 September 2021 at 20:06:59 UTC, Ali =C3=87ehreli wrot=
e:
 tl;dr Do you use 'const' or 'immutable' by-default for parameters and=
 for local data?
well i often ignore it but `const` (or often better yet, `inout` if there's any relation to a member of yours or if you return it)
'inout' has been useful in cases like you mention. For example, a=20 slice's elements should reflect the mutability of 'this'. I am mostly=20 interested in revising a beginner-oriented chapter, where 'inout'=20 doesn't exist yet.
 is better
 on function arguments, and `immutable` is better on internal members.

 The exception is when you are storing something from someone else, whe=
re
 immutable params might be more important.
I noticed that as well: For example, if a file name constructor=20 parameter is string, I don't need to copy the file name to a member.=20 (This actually appears later in the book where I realize constructor=20 arguments might better be 'immutable'.)
 But if you are looking and not
 touching, const or `in` is good.
'in' has been another question: It appears a lot in my book but I almost = never use it myself. Perhaps that's the answer? I would like that.=20 However, the proposed change of meaning of 'in' is also worrying but I=20 think it will strenghthen the case for it's use I guess.
 Aside: If 'const' is welcoming, why do we type 'string' for string
 parameters when we don't actually *require* immutable:
Unfortunate naming here... the convenient name encourages its use but =
it
 is indeed often suboptimal.
I agree. However, ironically and worryingly :), it just works most of=20 the time. Ali
Sep 22
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 22.09.21 22:06, Ali Çehreli wrote:
 Please excuse this thread here, which I know belongs more to the Learn 
 forum but I am interested in the opinions of experts here who do not 
 frequent that forum.
 
 tl;dr Do you use 'const' or 'immutable' by-default for parameters and 
 for local data?
 
 ...
No. I think `const` and especially `immutable` are great for plain old data types, especially data that has multiple references to it. For non-trivial user-defined data types, I think just using proper encapsulation is usually sufficient and more flexible.
Sep 22
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 9/22/21 1:48 PM, Timon Gehr wrote:

 No. I think `const` and especially `immutable` are great for plain old
 data types, especially data that has multiple references to it. For
 non-trivial user-defined data types, I think just using proper
 encapsulation is usually sufficient and more flexible.
You mean, providing "const access" to an encapsulated entity through an accessor. Sure... Still, do you make 'const' local objects of such types or are they auto? const a = MyStruct(); immutable b = MyStruct(); auto c = MyStruct(); // This one? Ali
Sep 23
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
My guideline is that most stuff is mutable, so there's little 
reason to try to make it const. For most simple types like 
scalars and arrays const is relatively cheap and useful, but its 
usefulness decreases with complexity of the type, the more 
complex is the type the more likely it's mutable. Strings often 
benefit from immutability.
Sep 22
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 9/22/21 2:34 PM, Kagamin wrote:
 My guideline is that most stuff is mutable, so there's little reason to
 try to make it const.
I've been putting const as much as possible: const arr = foo(); However, as soon as I decide to mutate the result, I change it to auto: auto arr = foo(); arr[0] += 42; So, defensive programming prescribes 'const' and it seems like I did protect myself from accidental mutation. But how common are these accidental mutations? Is it so common to worth the neural activity and needing to change the code when it's not an accidental mutation? As I hinted in some of my DConf presentations, I started to question the value of some programming constructs. For example, I don't use 'private' unless a type gets complicated enough to protect its invariants. I agree that 'private' is useful for API types to change implementations freely but I still question: If I already documented how to use the API, even with examples; but the users went ahead and reached inside and used members of my API structs... I am in the opinion that if I still have the right to change the implementation. I don't think it's the end of the world if the users have to change their code.
 For most simple types like scalars and arrays
 const is relatively cheap and useful, but its usefulness decreases with
 complexity of the type, the more complex is the type the more likely
 it's mutable. Strings often benefit from immutability.
There are cases where I remove a 'const' just to make the code compile instead of fighting the type system and it just works. The fact that I am embarrassed to write these must be telling: Either I am becomming more and more mediocre as a programmer (as I gain more experience!), or maybe there is something else here. :) Ali
Sep 23
prev sibling next sibling parent reply Mathias LANG <geod24 gmail.com> writes:
On Wednesday, 22 September 2021 at 20:06:59 UTC, Ali Çehreli 
wrote:
 tl;dr Do you use 'const' or 'immutable' by-default for 
 parameters and for local data?
Short answer: `immutable` is a special case that is way too prominent in D. `const` is my go-to *when I need it*.
 - It is said that 'immutable' is a stronger type of const, 
 which at first sounds great because if 'const' is good, 
 'immutable' should be even better, right? Unfortunately, we 
 can't make everything 'immutable' because 'const' and 
 'immutable' have very different meanings at least in parameter 
 lists.
I think we should not fall for the fallacy of "more attributes == good". More attributes just means more restrictions. Why do we need more restrictions ? To make our life easier when writing, reading, or changing code. The less a piece of code can do, the easier it is to understand. I think that fallacy started with ` safe`: It is good to make everything ` safe`, right ? Can't go wrong with memory safety. And `pure` also, because not using global is good, right ? Except it starts to be very impractical for `pure`, so we have hacks like save-set-reset `errno` to accommodate for it, because we *want* things to be `pure`, although they mutate global state. And then enters `nothrow`, and ` nogc`, and those categorically shouldn't be treated the same as ` safe`. Not everything needs to be `nothrow` / ` nogc`. And not everything needs to be constified.
 I am seeking simple guidelines like C++'s "make everything 
 const."
I don't think it's [that simple](https://youtu.be/qx22oxlQmKc?t=923).
 Aside: If 'const' is welcoming, why do we type 'string' for 
 string parameters when we don't actually *require* immutable:
This is IMO "D's greatest mistake". When Sociomantic did the D1 -> D2 transition, we came up with three aliases: ```D alias mstring = char[]; alias cstring = const(char)[]; alias istring = immutable(char)[]; ``` Our guidelines were simple: - Template Parameter ? => `istring`; - Mutable buffer => `mstring` (usually `ref` too as we used `assumeSafeAppend` a lot); - Otherwise, it's most likely `cstring`; The few exceptions I can remember were some constructors / setters for things that we knew would be constructed once per application lifetime (e.g. command-line parser). Obviously, `cstring` ended up being used in most places. It's now one of the first alias I define whenever I start a project that will deal with strings.
 But wait! It works above only because 'front' happened to work 
 there. The problem is, 's' is not an input range; and that may 
 matter elsewhere:
IMO that's another problem. Ranges generally don't work (well) with `const` (or `immutable`) qualified elements, nor do they work well with non-copyable data.
 Or, should 'immutable' be preferable here because it's 
 implicitly shared, which may be useful in the future?

 Are there simple guidelines around this topic? Please? :)

 Personally, I generally ignore 'immutable' (except, implicitly 
 in 'string') both for parameters and local data.
If we go back to those keywords definition: - `const`: Cannot be modified through this instance; - `immutable`: Cannot be modified through *any* instance; Now there's a very annoying (not so) corner case with the second definition: It binds the lifetime of the memory to the lifetime of *any* instance. Because if the data is destroyed, it means an instance can modify it, which contradicts `immutable`. Luckily, D has a GC, meaning we get away pretty easily with this... Until we want every part to function independently and then we don't. This was an intractable problem before `scope` had any effect, because you could stack-allocate an `immutable` array and they slice it, and boom! Now the only problem is that we need to combine immutable and smart pointers, so that we can properly free the memory whenever the last reference goes out of scope (remember AfixAllocator and Andrei's talk?). ------ But I am digressing from your original question. Want a simple set of guidelines ? Here's what we do: - Enable `-preview=in` (with DMD >= v2.095) and pass parameters by `in` for functions (even for types without indirections); - Avoid `in` for parameters which are stored (setters, ctors...); - Use `const` for parameter with indirections if possible; - Use `immutable` if needed (e.g. need to forward to a function that uses `immutable`); - Use mutable parameters otherwise; - For local data, don't make it `const` or `immutable` unless needed: If a function is so long that it doesn't fit on one's screen, break it down; It's simple, it works, it looks good.
Sep 22
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 9/22/21 6:29 PM, Mathias LANG wrote:

 alias cstring = const(char)[];
I've been thinking about that myself. Good to see it being used.
 - Enable `-preview=in` (with DMD >= v2.095) and pass parameters by `in`
2.094 perhaps? https://dlang.org/changelog/2.094.0.html#preview-in Yeah, this meaning of 'in' makes a lot of sense to me. In fact, Adam mentioned 'in' as well. I can make it "standard" by recommending it in the book. >:) Ali P.S. I will respond to most other comments after digesting them a bit. :)
Sep 22
parent reply Temtaime <temtaime gmail.com> writes:
On Thursday, 23 September 2021 at 03:31:01 UTC, Ali Çehreli wrote:
 On 9/22/21 6:29 PM, Mathias LANG wrote:

 alias cstring = const(char)[];
I've been thinking about that myself. Good to see it being used.
 - Enable `-preview=in` (with DMD >= v2.095) and pass 
 parameters by `in`
2.094 perhaps? https://dlang.org/changelog/2.094.0.html#preview-in Yeah, this meaning of 'in' makes a lot of sense to me. In fact, Adam mentioned 'in' as well. I can make it "standard" by recommending it in the book. >:) Ali P.S. I will respond to most other comments after digesting them a bit. :)
Surely, i'm using 'in' anywhere i need const. I'm avoiding using explicit const/immutable.
Sep 23
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 9/23/21 2:41 AM, Temtaime wrote:

 Surely, i'm using 'in' anywhere i need const. I'm avoiding using 
 explicit const/immutable.
(You meant for parameters.) Makes sense! :) Ali
Sep 23
prev sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 9/22/21 6:29 PM, Mathias LANG wrote:

 I think we should not fall for the fallacy of "more attributes == good".
In addition to what you say, complexity in a tool is detrimental for adoption, usability, undestandability, maintenance, etc.
 I don't think it's [that simple](https://youtu.be/qx22oxlQmKc?t=923).
Excellent presentation. I have always respected Herb Sutter, am jealous of his methodical approach to problems, and happy to have met him at SD 2000 to chat briefly while having his book signed. Although most of what he presents is either already in D or discussed for D, he (and many other great minds) are still working for improving C++. I don't approve his ignoring D in the context of that talk; he is ever finds its way into C++, it will be again "other languages are taking from us but they never acknowledge it" (what I remember from past a Bjarne Stroustrup keynote speech). It takes a different kind of personality to realize that all improvements that one is thinking for C++ is already in D and to see it reason enough to put efforts in. (I know Herb Sutter knows about D because he has been rubbing shoulders with Andrei. He was a co-author of a proposal to add D's 'static if' for C++, where D was referenced.) I like how he says "I can't teach it. It's too complicated." Exactly! That's why I am here on this thread. Some of what he presented relates to D: - in, out, and ref - Some of Walter's efforts for live (when proposed improved C++ compilers analyzing flow graphs) - In a D constructor, initialization is "first assignment". - " = void"
 Our guidelines were simple:
 - Template Parameter ? => `istring`;
Of course, manifest constants (e.g. enum) as well.
 - `const`: Cannot be modified through this instance;
 - `immutable`: Cannot be modified through *any* instance;
Allow me to stay on an unnecessary detail: Those are very common definitions that are repeated elsewhere in this thread. However, partly encouraged by Herb Sutter's stressing "intents", I will explain my different take on it: Parameters are parts of a contract between the function and the caller; they must be described from the function's point of view: - When a function parameter is 'const', it is the function's telling to the caller "I promise I will not mutate it". (And of course the compiler enforces it.) - When a function parameter is 'immutable', it is the function's telling to the caller "I require immutable (with the literal meaning here)". Perhaps not an important difference but I think such details are important for teachability. And there is a difference between parameters and variables because the latter is not a requirement like it is for functions. TO me, an 'immutable' variable carries a meaning for it to be required to be so; 'const' does not have that meaning for a variable. That's why I like 'const' for variables like the following: const a = 42; // Simple immutable b = 42; // Brings more meaning and supposition Ali
Sep 23
prev sibling next sibling parent Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Wednesday, 22 September 2021 at 20:06:59 UTC, Ali Çehreli 
wrote:
 ....
imho they can be interpreted like this for parameters: const: I won't change it. immutable: I won't change it, and expect no one else to change it too. Regards, Alexandru.
Sep 23
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Sep 22, 2021 at 01:06:59PM -0700, Ali ehreli via Digitalmars-d wrote:
 Please excuse this thread here, which I know belongs more to the Learn
 forum but I am interested in the opinions of experts here who do not
 frequent that forum.
 
 tl;dr Do you use 'const' or 'immutable' by-default for parameters and
 for local data?
Nope. Probably should, but I don't because the transitivity of const/immutable makes it very difficult to use correctly in complex data structures. I *have* tried this before in various cases, but found that it usually requires a lot of busywork (oops compiler says can't pass const here, can't accept const there, OK let's fix this function, oops, the function it calls also needs const, oops, now it can't accept mutable, must use inout instead, oops, inout is a pain to get right, forget this, I give up), and the benefits, at least so far, are minimal -- it has maybe found 1 or 2 bugs in my code, but only after many hours of refactoring just to make everything const-correct. So IMHO, not worth the effort. Where I've had most success with const/immutable is with leaf-node modules implementing simple data structures, i.e., at the bottom of the dependency chain, where other code depends on it but it doesn't depend on other code. And perhaps one or two levels above that. But beyond that, it quickly becomes cumbersome and with benefits not proportional to the amount of effort required to make it work.
 Long version:
 
 It was simpler in C++: We would make everything 'const' as much as
 possible.  Unfortunately, that doesn't work in D for at least two
 reasons:
 
 1) There is 'immutable' as well
It's very simple. Use const when the data could be either immutable or mutable (usually this applies to function parameters), immutable everywhere else. But since POD types make copies anyway, in practice I find const/immutable not worth the complexity with PODs. Strings are perhaps the most notable exception to this IME.
 2) There is no head-const (i.e. no 'const' pointer to mutable data;
 i.e.  "turtles all the way down")
TBH, I see this as an advantage. However, there *are* certainly cases where you really want head-const, but there's no in-language solution (and Phobos' Rebindable isn't a 100% solution).
 Further complications:
 
 - Reference semantics versus copy semantics; by type (e.g. slices), by
 the 'ref' keyword, by a member of a struct that has reference
 semanticts (struct is by-copy; but a member may not be), etc.
Yeah, once you get beyond the most trivial data structures, you start running into problems with const/immutable due to the complicated interactions with everything else.
 - It is said that 'immutable' is a stronger type of const, which at
 first sounds great because if 'const' is good, 'immutable' should be
 even better, right? Unfortunately, we can't make everything
 'immutable' because 'const' and 'immutable' have very different
 meanings at least in parameter lists.
I think it's fallacious to try to put const/immutable on a scale of "better" or "worse". They serve different purposes: const is to guarantee the recipient of a reference cannot modify the referent; immutable is to guarantee the referent itself can never be modified. The former is like lending your data to somebody that you don't trust -- you yourself can still touch the data but the recipient is only allowed to look at it. The latter is when the data itself cannot ever change, not even by yourself.
 - Parameters versus local data.
 
 I am seeking simple guidelines like C++'s "make everything const."
Parameters are where the const/immutable are most differentiated. Local data -- it depends. If you got it from another function call, it may already come as const or immutable, so you just have to follow what you receive (or weaken immutable to const if you wish, though I don't see the point unless you plan to rebind it to mutable later on). If it's pure POD locally-initialized, just use immutable.
 Let's start with what I like as descriptions about parameters:
 
 1) 'const' parameter is "welcoming" because it can work with mutable,
 'const', and 'immutable'. It (sometimes) means "I am not going to
 mutate your data."

 2) 'immutable' parameter is "selective" because it can work only with
 'immutable'. It means "I require immutable data."
Const is like a 3rd party contract to ensure that they don't damage your data. They cannot change it, but someone who has write access (i.e., a mutable reference) still may. Immutable is like data made of steel: you cannot change it even if you wanted to. I.e., *nobody* has write access to it.
 But it's not that simple because a 'const' parameter may be a copy of
 the argument, in which case, it means "I will not mutate *my* data."
 This is actually weird because we are leaking an implementation detail
 here: Why would the caller care whether we mutate our paramener or
 not?
In this case, I'd use `in` instead: this tells the caller "this parameter is an input; its value will not change afterwards". For PODs, it already doesn't change, but `in` reads nicer than `const`. :-D
 // Silly 'const':
 void foo(const int i) {
   // ...
 }
This reads less silly: void foo(in int i) { ... } :-) [...]
 Aside: If 'const' is welcoming, why do we type 'string' for string
 parameters when we don't actually *require* immutable:
 
 // Unenecassary 'immutable' but I do this everywhere.
 void printFirstChar(string s) {
   write(s.front);
 }
 
 It should have better been const:
 
 void printFirstChar(const char[] s) {
   write(s.front);
 }
 
 But wait! It works above only because 'front' happened to work there.
 The problem is, 's' is not an input range; and that may matter
 elsewhere:
 
   static assert(isInputRange!(typeof(s)));  // Fails. :(
It makes me cringe everytime someone writes const/immutable without parentheses, because it's AMBIGUOUS, and that's precisely the problem here. What you *really* meant to write is const(char)[], but by omitting the parentheses you accidentally defaulted to const(char[]), which no longer works as a range. Also, const(char)[] works as long as you don't need to rebind. But if you do, e.g., in a parsing function that advances the range based on what was consumed, you run into trouble: // N.B.: ref because on exit, we update input to after the // token. void consumeOneToken(ref const(char)[] input) { ... } string input = "..."; consumeOneToken(input); // Oops, compile error On the surface, this seems like a bug, because input can be rebound without violating immutable (e.g., input = input[1..$] is valid). But on closer inspection, this is not always true: void evilFunction(ref const(char)[] input) { char[] immaMutable; input = immaMutable; // muahaha } string input = "..."; evilFunction(input); // oops, we just bound mutable to immutable This is why the compiler does not allow binding string (immutable(char)[]) to ref const(char)[]. But that also means you don't want to use const(char)[] when ref is involved. Instead, you want string: void consumeOneToken(ref string input) {...} // this works But then, this also means you can't pass in mutable char[]! So ultimately, one solution is, rebind string to const(char)[] in the *caller*, then pass it to the function: void consumeOneToken(ref const(char)[] input) { ... } string origInput = "..."; const(char)[] input = origInput; // ugly ugly consumeOneToken(input); // but at least this works now
 So only the elements of the string should be 'const':
 
 void printFirstChar(const(char)[] s) {
   write(s.front);
   static assert(isInputRange!(typeof(s)));  // Passes.
 }
 
 (Granted, why is it 'const' anyway? Shouldn't printFirstChar be a
 function template? Yes, it should.)
Why should it be? Using a template here generates bloat for no good reason. Using const(char)[] makes it work for either case with just one function in the executable.
 So, what are your guidelines here?
 
 More important to me: How do you define your local data that should
 not be mutated?
 
   const     c = SomeStruct();
   immutable i = SomeStruct();
 
 In this case, 'const' is not "welcoming" nor 'immutable' is
 "selective" because these are not parameters; so, the keywords have a
 different meaning here: With local data, they both mean "do not
 mutate". Is 'immutable' better here because we may pass that data to
 an immutable-requiring function?  Perhaps we should learn from string
 and make it really 'immutable'? But it's not the same because here
 'immutable' applies to the whole struct whereas 'string's immutability
 is only with its elements. There! Not simple! :)
Ugh. I wish people would stop writing const/immutable without parentheses. ;-) Always write it with parentheses, and the problem goes away: you write const(T[]) when you wish the whole object to be const (resp. immutable), and you write const(T)[] when you want individual elements to be immutable but the outer structure to be mutable. But yeah, this only works at the bottom-most level of abstraction. Once your type becomes more complex, it quickly devolves into a cascade of exploding const/immutable complexity, and you start running into lovely conundrums like how to make const(SomeStruct!T) == SomeStruct!(const(T)). Also, const for local variables are really only necessary if you got the data from a function that returns const; otherwise, it's practically no different from immutable and you might as well use immutable for stronger guarantees. [...]
 Personally, I generally ignore 'immutable' (except, implicitly in
 'string') both for parameters and local data.
[...] Immutable is powerful because it has very strong guarantees. Unfortunately, these very strong guarantees also make its scope of applicability extremely narrow -- so narrow that you rarely need to use it. :-D T -- Frank disagreement binds closer than feigned agreement.
Sep 24
next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 9/24/21 10:20 AM, H. S. Teoh wrote:

 tl;dr Do you use 'const' or 'immutable' by-default for parameters and
 for local data?
Nope. Probably should, but I don't because the transitivity of const/immutable makes it very difficult to use correctly in complex data structures.
That's disconcerting and matches my experience as well.
 So IMHO, not worth the effort.
I am going there as well. However, you seem to have some guidelines, which makes me think you take advantage of immutability as long as it is practical.
 Where I've had most success with const/immutable is with leaf-node
 modules implementing simple data structures, i.e., at the bottom of the
 dependency chain, where other code depends on it but it doesn't depend
 on other code. And perhaps one or two levels above that. But beyond
 that, it quickly becomes cumbersome and with benefits not proportional
 to the amount of effort required to make it work.
That answers one of my questions: There are cases where some local variables cannot be const or immutable because they will inevitably passed to high-level functions.
 Use const when the data could be either immutable or
 mutable (usually this applies to function parameters),
That's the simplest case to agree on: Yes, function parameters should be 'const'.
 immutable everywhere else.
This matches what I currently have in the book, which bugs me a little bit. (Note the following example comes with a bonus minor and off-topic issue, which may be related to your complaints about complexity hindering immutability.) ``` import std.algorithm; import std.range; void foo(const(int)[] input) { immutable halfLength = input.length / 2; immutable processed = input.map!(i => immutable(int)(i * i)).array; // ... } void main() { foo([ 1, 2 ]); } ``` Main issue: Ok, local variables are defined as immutable there. However, I see that as being superfluous (presumptuous?) because I definitely did not mean "*others* may not mutate it please". All I meant is immutable. So, using immutable carries that extra meaning, which is not really used there. <off-topic> Bonus minor and off-topic issue: I think we have an issue in the type system. If we replace `immutable(int)(i * i)` with just `i * i`, we get the following compilation error: Error: cannot implicitly convert expression `array(map(input))` of type `const(int)[]` to `immutable(int[])` The problem is, `i * i` has no indirections and is starting life afresh. It can be `immutable`. But I understand how the type of the right-hand side is separate from the type of the left-hand side. Let's try casting the right-hand side: auto processed = cast(immutable)input.map!(i => i * i).array; Ok, it works! :) (And of course, `auto` does not mean mutable there.) More off-topic: Today, I learned that the type of a vector in Rust is determined at first use. (Or something like that.) So, if `auto` were legal there in D, it would be demonstarted like the following in D: auto[] arr; // No type assigned yet // ... arr ~= 42; // Ok, the type of arr is int[] Still statically-typed... Too flexible for D? Perhaps not because we have something similar already, which I think Rust does not have: The return type of an auto function is determined by the first return statement in D. </off-topic>
 I think it's fallacious to try to put const/immutable on a scale of
 "better" or "worse".
Like you and others, I agree and I tried to convey that point.
 Parameters are where the const/immutable are most differentiated. Local
 data -- it depends. If you got it from another function call, it may
 already come as const or immutable, so you just have to follow what you
 receive (or weaken immutable to const if you wish, though I don't see
 the point unless you plan to rebind it to mutable later on).
Unfortunately, intermediate functions do weaken `immutable` in the name of being "more useful". (This is related to my "functions should be templates" comment below. void main() { immutable a = [ 1, 2, 3 ]; // Passes the array through foo() and bar() immutable b = foo(a); // Error: cannot implicitly convert expression // `foo(cast(const(int)[])a)` of type // `const(int)[]` to `immutable(int[])` } auto foo(const(int)[] arr) { return bar(arr); } auto bar(T)(T arr) { return arr; } The code compiles if foo() is a template because in that case the type is preserved as `immutable(int)[]`. Off-topic: I am sure you are aware of the magic that happened there. The types are *usefully* different: immutable(int[]) --> The type of 'a' in main. immutable(int)[] --> The type of 'arr' parameter of foo().
 If it's pure POD locally-initialized, just use immutable.
Ok, I used `immutable` for non-POD and some strange thing happened. :)
 In this case, I'd use `in` instead: this tells the caller "this
 parameter is an input; its value will not change afterwards". For PODs,
 it already doesn't change, but `in` reads nicer than `const`. :-D
I agree. I have many examples in the book where parameters are 'in'. But I don't have a single 'in' keyword in my code at work. :( I will start taking advantage of --preview=in.
 void printFirstChar(const char[] s) {
    write(s.front);
 }

 But wait! It works above only because 'front' happened to work there.
 The problem is, 's' is not an input range; and that may matter
 elsewhere:

    static assert(isInputRange!(typeof(s)));  // Fails. :(
It makes me cringe everytime someone writes const/immutable without parentheses, because it's AMBIGUOUS, and that's precisely the problem here. What you *really* meant to write is const(char)[], but by omitting the parentheses you accidentally defaulted to const(char[]), which no longer works as a range.
Yes but confusingly `s.front` works.
 Also, const(char)[] works as long as you don't need to rebind. But if
 you do, e.g., in a parsing function that advances the range based on
 what was consumed, you run into trouble:

 	// N.B.: ref because on exit, we update input to after the
 	// token.
 	void consumeOneToken(ref const(char)[] input) {
 		...
 	}

 	string input = "...";
 	consumeOneToken(input);	// Oops, compile error

 On the surface, this seems like a bug, because input can be rebound
 without violating immutable (e.g., input = input[1..$] is valid). But on
 closer inspection, this is not always true:

 	void evilFunction(ref const(char)[] input) {
 		char[] immaMutable;
 		input = immaMutable; // muahaha
 	}

 	string input = "...";
 	evilFunction(input); // oops, we just bound mutable to immutable
This is an issue I am aware of from C, which manifests itself in two levels of pointer indirection. (I can't construct an example but I recognize it when I hit the issue. :) )
 (Granted, why is it 'const' anyway? Shouldn't printFirstChar be a
 function template? Yes, it should.)
Why should it be? Using a template here generates bloat for no good reason. Using const(char)[] makes it work for either case with just one function in the executable.
The example above is related to this issue. But I admit: These are not cases we face every day.
 Also, const for local variables are really only necessary if you got the
 data from a function that returns const; otherwise, it's practically no
 different from immutable and you might as well use immutable for
 stronger guarantees.
That answers a question but as I said above, `immutable` carries extra meaning and it's longer. ;)
 Immutable is powerful because it has very strong guarantees.
 Unfortunately, these very strong guarantees also make its scope of
 applicability extremely narrow -- so narrow that you rarely need to use
 it. :-D
Agreed. For example, I use `immutable` when I pass data between threads. (And implicitly, every time I use `string`. ;) ) Ali
Sep 24
prev sibling parent Kagamin <spam here.lot> writes:
On Friday, 24 September 2021 at 17:20:04 UTC, H. S. Teoh wrote:
 On the surface, this seems like a bug, because input can be 
 rebound without violating immutable (e.g., input = input[1..$] 
 is valid). But on closer inspection, this is not always true:

 	void evilFunction(ref const(char)[] input) {
 		char[] immaMutable;
 		input = immaMutable; // muahaha
 	}

 	string input = "...";
 	evilFunction(input); // oops, we just bound mutable to 
 immutable
I write parsers as splitters: the function takes a string, splits it in two parts and returns them, or the parser is a struct that keeps the string inside.
Sep 28