difficulties with const structs and alias this / template functions

[Stanislav Blinov]

On Monday, 19 November 2018 at 14:51:14 UTC, Steven Schveighoffer 
wrote:

> Or just use inout. This is literally what inout is for:
>
> inout(q32) toQ32 inout {
>     return q32(x);
> }
>
> This should transfer whatever constancy of the original is used 
> for the return value.

Yep, I just wanted to explicitly point out the `this T`, which 
gets overlooked way too often.

> However, I'd state that this is really a workaround for a 
> language deficiency. In reality, I would surmise (without 
> knowing the implementation) that q32's state is a complete copy 
> of the q16 state. So there is no reason to apply any constancy 
> copying from the source to the destination.
> The real problem is that mutating operators on struct rvalues 
> are always allowed, because `this` is always passed by 
> reference. For the most part this is a harmless drawback, but 
> because there is no way to "opt out" of this, you can't stop it 
> when it really doesn't make sense (as in this case).

Sure. At first I was perplexed why Dennis' a /= 2 even compiled. 
Then I saw the alias this.

> I have long wanted a way to direct IFTI how to define its 
> parameters base on the arguments. We have a simple adjustment 
> for arrays, where the array is always unqual'd before IFTI 
> define the parameter.
>
> In other words:
>
> const int[] arr;
>
> void foo(T)(T t) {... }
>
> foo(arr) => T = const(int)[], not const(int[])
>
> I think Andrei in the last dconf proposed we do more of this 
> with other types (for ranges, specifically). But I think it 
> would be good to also define other conversions possibly 
> manually.

I agree completely. Like Dennis' code, or that gcd example from 
Phobos, it'd really help to be able to be explicit in the 
signature, not creative in implementation :) Especially 
considering that Unqual is a high-yield type system nuke.