• Cecil Ward (19/19) May 29 2023 I have often come into difficulties where I wish to have one
• Paul Backus (6/18) May 29 2023 Normally you would use const for this, since a const parameter
• =?UTF-8?Q?Ali_=c3=87ehreli?= (6/10) May 29 2023 'const' should take both immutable and mutable. Can you show your case
• Cecil Ward (7/18) May 30 2023 T2 foo( in T1 x ) { return bar( x ) };
• Cecil Ward (13/37) May 30 2023 I have to admit that I don’t really understand immutable. I have
• Dom DiSc (24/33) May 31 2023 There are two perspectives: that of the value handed to a
• Cecil Ward (14/49) May 31 2023 Dom, you explain it well. I’m just too stupid. Literally, as I’m
• Steven Schveighoffer (5/10) May 30 2023 In cases where const doesn't suffice, inout might. inout has a feature

Cecil Ward <cecil cecilward.com> writes:

I have often come into difficulties where I wish to have one 
routine that can be called with either immutable or (possibly) 
mutable argument values. The argument(s) in question are in, 
readonly, passed by value or passed by const reference. Anyway, 
no one is trying to write to the items passed in as args, no 
badness attempted.

When I call the routine from one place with an argument that is 
immutable and then from another that is not, or it could be const 
as well, or not, that’s when I get all kinds of type mismatch 
errors. And I certainly don’t want to pour cast-like type 
conversion operations over all the place at these problem 
occurrences. it’s surely asking for problems.

Could I make the one routine into a template? Even if I did, that 
would perhaps create additionally problems, since even if it all 
worked and instantiated either immutable or mutable forms of the 
routine, what happens if I have two args and they have a mixture 
of immutable and no immutable args ? So nargs * 2 ( or more) 
possibilities?

I’m out of my depth here.

Paul Backus <snarwin gmail.com> writes:

On Tuesday, 30 May 2023 at 02:57:52 UTC, Cecil Ward wrote:
 I have often come into difficulties where I wish to have one 
 routine that can be called with either immutable or (possibly) 
 mutable argument values. The argument(s) in question are in, 
 readonly, passed by value or passed by const reference. Anyway, 
 no one is trying to write to the items passed in as args, no 
 badness attempted.

 When I call the routine from one place with an argument that is 
 immutable and then from another that is not, or it could be 
 const as well, or not, that’s when I get all kinds of type 
 mismatch errors. And I certainly don’t want to pour cast-like 
 type conversion operations over all the place at these problem 
 occurrences. it’s surely asking for problems.

Normally you would use const for this, since a const parameter 
can accept either a mutable or an immutable argument. If const 
isn't working for you, then there's probably something else going 
on that you haven't mentioned. Can you post an example of the 
kind of code that gives you these errors?

=?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:

On 5/29/23 19:57, Cecil Ward wrote:

 I wish to have one routine
 that can be called with either immutable or (possibly) mutable argument
 values.

'const' should take both immutable and mutable. Can you show your case 
with a short example?

 Could I make the one routine into a template?

That could work but give 'in' parameters a try:

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

Ali

Cecil Ward <cecil cecilward.com> writes:

On Tuesday, 30 May 2023 at 04:15:22 UTC, Ali Çehreli wrote:
 On 5/29/23 19:57, Cecil Ward wrote:

 I wish to have one routine
 that can be called with either immutable or (possibly)

 mutable argument
 values.

 'const' should take both immutable and mutable. Can you show 
 your case with a short example?

 Could I make the one routine into a template?

 That could work but give 'in' parameters a try:

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

 Ali

T2 foo( in T1 x ) { return bar( x ) };

It was with something vaguely like the above that I had to remove 
the in (templatised generic function possibly) in order to get it 
to compile with GDC or LDC on godbolt.org (or d.godbolt.org) 
latest versions available. -O3 -release/-frelease 
-march=native/-mcpu-native

Cecil Ward <cecil cecilward.com> writes:

On Wednesday, 31 May 2023 at 03:23:01 UTC, Cecil Ward wrote:
 On Tuesday, 30 May 2023 at 04:15:22 UTC, Ali Çehreli wrote:
 On 5/29/23 19:57, Cecil Ward wrote:

 I wish to have one routine
 that can be called with either immutable or (possibly)

 mutable argument
 values.

 'const' should take both immutable and mutable. Can you show 
 your case with a short example?

 Could I make the one routine into a template?

 That could work but give 'in' parameters a try:

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

 Ali

 T2 foo( in T1 x ) { return bar( x ) };

 It was with something vaguely like the above that I had to 
 remove the in (templatised generic function possibly) in order 
 to get it to compile with GDC or LDC on godbolt.org (or 
 d.godbolt.org) latest versions available. -O3 
 -release/-frelease -march=native/-mcpu-native

I have to admit that I don’t really understand immutable. I have 
an idea that it could mean that an object has an address in ROM, 
so its value will never change. Maybe const doesn’t give you such 
a strong guarantee, disallows ‘you’ from modifying it but others 
might do so, but who knows. Without a guarantee as strong as the 
first idea I can’t really understand how const can work properly. 
"You treat it as const so do not modify it, but it might not be 
eternally fixed and  unchanging" that doesn’t seem to have enough 
value to me. But maybe I’ve got the whole thing wrong.

In an architecture where you have strongly typed (tagged ? 
segmented?) different kinds of addresses, I can see why you might 
be getting type mismatch errors when passing addresses around.

Dom DiSc <dominikus scherkl.de> writes:

On Wednesday, 31 May 2023 at 03:29:33 UTC, Cecil Ward wrote:
 I have to admit that I don’t really understand immutable. I 
 have an idea that it could mean that an object has an address 
 in ROM, so its value will never change. Maybe const doesn’t 
 give you such a strong guarantee, disallows ‘you’ from 
 modifying it but others might do so, but who knows.

There are two perspectives: that of the value handed to a 
function and that of the function taking the value.
"immutable" (or "mutable") is a property of the value, "const" is 
a property of the function.
If the function can work with mutable values, but in fact doesn't 
mutate them itself, it could also work with immutable values. The 
fact that others could modify your "const" value doesn't matter 
for immutable values, because they of course can't be modified by 
others. For the function it doesn't matter, because it only 
guarantees not to modify it itself, don't care about what other 
can or can't do.

 Without a guarantee as strong as the first idea I can’t really
 understand how const can work properly. "You treat it as const
 so do not modify it, but it might not be eternally fixed and
 unchanging" that doesn’t seem to have enough value to me.

Why? What guarantee are you missing?
Your function can work with mutable data, so you don't care if it 
can be modified also by others.
Now it happens that you doesn't modify the data. So why shouldn't 
you be able to work on data that guarantees that it also will not 
be changed by others? You don't care for such modification anyway.

The meaning of "immutable" is: I cannot be modified. Not by you 
and not by anybody else. It's a property of a value.
The meaning of "mutable" is: I can be modified by anybody. Work 
with me only if that is ok for you. It's a property of a value.
The meaning of "const" is: I don't care if others modify the data 
or not, I won't modify it myself. It's a property of a function.

Cecil Ward <cecil cecilward.com> writes:

On Wednesday, 31 May 2023 at 09:14:49 UTC, Dom DiSc wrote:
 On Wednesday, 31 May 2023 at 03:29:33 UTC, Cecil Ward wrote:
 I have to admit that I don’t really understand immutable. I 
 have an idea that it could mean that an object has an address 
 in ROM, so its value will never change. Maybe const doesn’t 
 give you such a strong guarantee, disallows ‘you’ from 
 modifying it but others might do so, but who knows.

 There are two perspectives: that of the value handed to a 
 function and that of the function taking the value.
 "immutable" (or "mutable") is a property of the value, "const" 
 is a property of the function.
 If the function can work with mutable values, but in fact 
 doesn't mutate them itself, it could also work with immutable 
 values. The fact that others could modify your "const" value 
 doesn't matter for immutable values, because they of course 
 can't be modified by others. For the function it doesn't 
 matter, because it only guarantees not to modify it itself, 
 don't care about what other can or can't do.

 Without a guarantee as strong as the first idea I can’t really
 understand how const can work properly. "You treat it as const
 so do not modify it, but it might not be eternally fixed and
 unchanging" that doesn’t seem to have enough value to me.

 Why? What guarantee are you missing?
 Your function can work with mutable data, so you don't care if 
 it can be modified also by others.
 Now it happens that you doesn't modify the data. So why 
 shouldn't you be able to work on data that guarantees that it 
 also will not be changed by others? You don't care for such 
 modification anyway.

 The meaning of "immutable" is: I cannot be modified. Not by you 
 and not by anybody else. It's a property of a value.
 The meaning of "mutable" is: I can be modified by anybody. Work 
 with me only if that is ok for you. It's a property of a value.
 The meaning of "const" is: I don't care if others modify the 
 data or not, I won't modify it myself. It's a property of a 
 function.

Dom, you explain it well. I’m just too stupid. Literally, as I’m 
on strong pain drugs all the time, so things are a bit fuzzy. As 
a professional C programmer for some years, I understood the word 
const and used it all the time, as much as possible at every 
opportunity, so I had some expectations. But the errors I’m 
getting don’t fit in with the previous understanding I had with 
the familiar ‘const’ keyword and make me think there must be 
something else going on. So I will need to capture an example in 
the wild, cage it and bring it in for scientific examination.

I can’t ask for an explanation of things going on that you can’t 
inspect for yourself, obviously. And I don’t understand what the 
problem is with using in as much as possible yet having to remove 
it sometimes when something immutable is in use.

Steven Schveighoffer <schveiguy gmail.com> writes:

On 5/29/23 10:57 PM, Cecil Ward wrote:
 I have often come into difficulties where I wish to have one routine 
 that can be called with either immutable or (possibly) mutable argument 
 values. The argument(s) in question are in, readonly, passed by value or 
 passed by const reference. Anyway, no one is trying to write to the 
 items passed in as args, no badness attempted.

In cases where const doesn't suffice, inout might. inout has a feature 
that it can be used in cases where a const nested behind multiple 
references would not work.

-Steve