• d-bugmail puremagic.com (36/36) Apr 12 2021 https://issues.dlang.org/show_bug.cgi?id=21823

d-bugmail puremagic.com writes:

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?

--