digitalmars.D.bugs - [Issue 21823] New: IFTI type conversions should apply to all types.
- d-bugmail puremagic.com (36/36) Apr 12 2021 https://issues.dlang.org/show_bug.cgi?id=21823
https://issues.dlang.org/show_bug.cgi?id=21823 Issue ID: 21823 Summary: IFTI type conversions should apply to all types. Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nobody puremagic.com Reporter: qs.il.paperinik gmail.com https://dlang.org/spec/template.html#ifti-conversions basically states that qualifiers are not inferred for the first layer of indirection for pointers and slices: f(T)(T a); called with a const(int[]) infers T to const(int)[] as it does for const(int*) to const(int)*. This apparently falls short for any other type. const int myConstant = returns!int; f(myConstant); // calls f!(const int)(myConstant) There is no reason to infer `const int` when calling it with a local variable that happens to be declared `const`. Worse, `f` looks to the author as `a` would be mutable on the first layer of indirection unless `T` is a non-POD aggregate type. (Note: When it `T` is a non-POD aggregate type like a class or a struct with indirections, removing the qualifier is not sound and cannot be done autmatically.) On the other hand, there is no simple way to define `f` such that calling `f` with a `const int` local results in a mutable parameter `a` when using IFTI: * One can call `f` like `f!int(myConstant)`, but honestly, who does that? We want IFTI. * One can define `f` using `Unqual!T` as the parameter type, but then IFTI fails and we want IFTI. Is there even an advantage to infer `const int` on IFTI? --
Apr 12 2021