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.

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?

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

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

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.

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.

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.