copy must be const?!?

[Dom DiSc]

On Friday, 26 July 2024 at 10:04:45 UTC, Jonathan M Davis wrote:
> On Friday, July 26, 2024 2:17:21 AM MDT Dom DiSc via 
> Digitalmars-d-learn wrote:
>> If you are not able to construct a mutable copy of a type, why 
>> on earth are you handing it over by value?!?
>
> Why not?

Because you can't make a mutable copy?

> Structs are [...] often pseudo-reference types. [...]
> such types can often work just fine with const copies, because 
> the data that's shared between objects is const or immutable.

Then declare the template to take a const parameter.

>> ```d
>> immutable MyNonCopyableType x;
>> MyNonCopyableType y = x; // compile error?
>> ```
>
> If you can't get a mutable copy of MyNonCopyableType, then yes, 
> you'll get a compiler error.

This is why you should get the same error, if the compiler cannot 
create a mutable parameter-by-value copy.

> In D, const is pretty much cancer, honestly. You do _not_ want 
> to use it for generic code if you can possible avoid it,

Why? In a template that guarantees not to modify a parameter by 
declaring it const, what bad can happen?

> because many, many types do not work with it at all.

At least reading it should never be a problem. And nothing more 
one want to do with a const parameter.

But I don't see your problem. I'm taking about situations where a 
const instance of a type IS ALREADY THERE (which will never be 
the case with any of your problematic types), and I want to have 
a mutable copy of them.
So if the compiler would discard the const from parameters that 
are anyway never const, that's a NOP. All is fine.

On the other hand if there is a const object, that should be an 
object of a type that indeed CAN provide mutable copies. This is 
also fine.

So, where is the problem if the compiler drops "const" from the 
by-value copy of a parameter?

> in situations where a type can be logically const (or which 
> could be const in C++), it cannot be const in D, because D's 
> const is simply too restrictive.

Sorry, but if a type is "logically const" (like a range) and you 
read it and thereby change it's internal state, then the template 
that guaranteed not to modify a parameter is very likely to 
destroy this internal state, and so you are much better of if 
this doesn't compile beforehand.

Some templates are simply not meant to work with all kinds of 
user defined types.

> If you declare the parameter to be const, then there are a lot 
> of types that won't work with the template.

Fine. If I can change the internal state via read-functions, I 
don't want to work with that bogous type. If my intention is not 
to modify an object, I'm perfectly ok that I can't use may of 
that fake-const types functions.

> On top of that, in many cases, getting a mutable copy would 
> give you completely incorrect behavior - e.g. if a range is a 
> range over a container, you need that range to point to the 
> elements in the container, and if the range refers to those 
> elements as const, then getting a mutable copy of those 
> elements would mean that they're no longer necessarily the same 
> elements which are in the container (they might be at the point 
> that the copy is made, but that won't necessarily stay true, 
> whereas it would if the elements aren't copied).

Ranges are a bad example, because they really cannot be const. 
They are completely unusable in a function not modifying them, 
because reading them is using them up. So a function taking a 
range as parameter indeed cannot guarantee not to modify it (at 
least not if it reads that parameters data at all).

> It's also the case that a lot of code simply avoids using const 
> altogether with user-defined types

Fine. Then you won't run into the problem I have. And indeed, as 
you weren't aware of this problem is an indicator that you are 
not really using const.

> Most anyone who tries to use D's const like you would in C++ 
> eventually stops, because D's const is simply too different 
> from C++'s const for that to work.

No, so far the C++ code I converted to D is working fine. And it 
is heavily using const - but it uses it correct, despite C++ 
doesn't enforce that. Maybe I never used C++ the way it was 
meant?!?

> And that's especially true with templated code, since if it has 
> to work with a large range of types, types which don't work 
> with const are going to be on the list.

Nope. Constraints work very good in guaranteeing that such types 
are NOT on the list of types the template is working with.

> On top of that, some common D idioms (e.g. ranges) can't work 
> with const, because they require mutation (a range can have 
> const elements, but the range itself cannot be const).

Jup. If a template takes a range, it should not take it const.
But I also won't take a range by value. As whatever I do will 
modify the range, why should I pretend to work on a copy of it? 
Take it by ref!