On 3/16/24 16:50, Walter Bright wrote:
> https://github.com/WalterBright/documents/blob/9dba63a4c2887bdb2b988c354ebb0d6bb44c4968/templatecast.md
> 
> DConf: https://dconf.org/2024/online/index.html#walterb

Issue: Subtyping under indirections remains magic.

```d
struct Mutability(bool mutable,T){
    static if(mutable){
        T payload;
    }else{
        const(T) payload;
    }
}

void main(){
    int[] a1 = [1,2,3];
    const(int)[] a2 = a1; // ok

    auto m1=[Mutability!(true,int)(1),
             Mutability!(true,int)(2),
             Mutability!(true,int)(3)];
    Mutability!(false,int)[] m2=m1; // error
}
```

(With variance annotations, this example would need some kind of support for variance annotations for template value parameters.)

On 3/18/24 02:28, Timon Gehr wrote:
> On 3/16/24 16:50, Walter Bright wrote:
>> https://github.com/WalterBright/documents/blob/9dba63a4c2887bdb2b988c354ebb0d6bb44c4968/templatecast.md
>>
>> DConf: https://dconf.org/2024/online/index.html#walterb
> 
> Issue: Subtyping under indirections remains magic.
> 
> ...

Another example of a similar kind of issue:

```d
struct S(T){
    T x;
}
void main(){
    S!int[] a = [S!int(1),S!int(2),S!int(3)];
    S!(const(int))[] b = a; // error
}
```

I think this one may be just an oversight in the prototype implementation.

On 3/18/24 02:11, Timon Gehr wrote:
> 
> 
> Drawbacks:
> 
> - Slightly more expensive to determine that subtyping holds. (First, you check the arguments according to the variance annotations, if that succeeds, you still have to perform the member-wise check.)
> 
> - This particular proposal would disallow a template type with variance of one template parameter varying based on one of the other template parameters.

A way to address this would be to also allow `struct S(+-T)`, which always just uses the field-wise check.

On 3/17/2024 5:32 PM, Timon Gehr wrote:
> I think this is a bit dangerous. (And on stream you seemed to argue that this has the potential to kill the proposal.)

I'm not convinced it is clean, nor am I convinced that it is dangerous. One solution would be simply to reject alias arguments that are functions. In general, the way may be to just keep rejecting things at compile time that aren't correct.

> I think the way to fix it would be to simply use a more strict standard than "must belong to the same template". Add an opt-in annotation to template parameters that indicates "this parameter may change in a const conversion". For other parameters, you still require them to match by default.
> 
> This way, people can opt into the behavior.

I hear you, but I am concerned about yet another annotation.

On 3/17/2024 5:38 PM, Timon Gehr wrote:
> This is a bit more tricky.

These already are supposed to work.

Oops.

This will not work, only the top level qualifiers are convertible, not the next level down.

On 3/17/2024 5:45 PM, Timon Gehr wrote:
> Issue: It does not seem to work yet for class references:

It only works for const conversion. Not for inheritance conversions. We could perhaps add the latter later, but I want to stick with const conversion only for now.

On 3/17/2024 6:17 PM, Timon Gehr wrote:
> Issue: I think the field names also have to match.

I think you're right.

On 3/17/2024 6:32 PM, Timon Gehr wrote:
> Another example of a similar kind of issue:
> 
> ```d
> struct S(T){
>      T x;
> }
> void main(){
>      S!int[] a = [S!int(1),S!int(2),S!int(3)];
>      S!(const(int))[] b = a; // error
> }
> ```
> 
> I think this one may be just an oversight in the prototype implementation.

That should work.