Bug 21823 – IFTI type conversions should apply to all types.

Status
NEW
Severity
normal
Priority
P3
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2021-04-12T13:58:16Z
Last change time
2024-12-13T19:15:50Z
Assigned to
No Owner
Creator
Bolpat
Moved to GitHub: dmd#19907 →

Comments

Comment #0 by qs.il.paperinik — 2021-04-12T13:58:16Z
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?
Comment #1 by robert.schadek — 2024-12-13T19:15:50Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/19907 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB