Implicit conversion to mutable if no indirections?

[Quirin Schroll]

On Tuesday, 6 September 2022 at 11:09:26 UTC, Loara wrote:
> On Tuesday, 6 September 2022 at 10:06:59 UTC, Quirin Schroll 
> wrote:
>
>> * Aforementioned `const(int*)` becoming `const(int)*`. That 
>> does not happen with custom `struct S(T)` automatically even 
>> in cases where it is provably correct, and there is no way to 
>> tell the D compiler that copies of `const(S!int)` are better 
>> understood to be `S!(const int)`.
>
> Consider
> ```d
> struct S(T){
>   T val;
>   int idx;
>
>   void inc(){
>     idx++;
>   }
> }
> ```
> then `s.inc()` is valid if `s` id `S!(const int)` but not if 
> `s` is `const S!int`!

Of course. That’s e.g. what a reference counted pointer would do.

> Again consider
> ```d
> struct S(T){
>    int dat;
>    T func(T dat){ ... }
> }
> ```
> in this example conversion of `S!(const int)` to `const S!int` 
> has much less sense. If you want to perform a such conversion 
> then you should instead introduce a "cloning" method:

This one isn’t even vaguely a container of `T`. You could argue 
about `int*`, and the case for `int[]` is obvious.

I’m not entirely sure what you want to tell me. In the cases of 
containers, it’s probably even possible to a large degree to use 
introspection to provide a wide-ranging `clone`. The relevant 
part is that when you clone, you have to be explicit.

There’s tension between stuff being handy when using known types 
and known functions, and stuff being simple using templates’ type 
arguments and function templates.