Qualify some function parameters under std.conv as const to reduce te…

[nordlow]

…mplate bloat

Trivial review, @thewilsonator.

[dlang-bot]

Thanks for your pull request and interest in making D better, @nordlow! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + phobos#8251"

[PetarKirov]

@nordlow unit-threaded fails to compile with this change:

Cloning https://github.com/atilaneves/unit-threaded (tag: v2.0.3)
Running the testsuite
~> case "$REPO_FULL_NAME" in
~> dub test
Running custom 'unittest' configuration.
Performing "unittest" build using /var/lib/buildkite-agent/builds/ci-agent-7d11ce47-aa1b-4308-a8a5-39b5bb0de700-2/dlang/phobos/build/distribution/bin/dmd for x86_64.
unit-threaded:from 2.0.3: building configuration "library"...
unit-threaded:exception 2.0.3: building configuration "library"...
unit-threaded:assertions 2.0.3: building configuration "library"...
unit-threaded:integration 2.0.3: building configuration "library"...
unit-threaded:mocks 2.0.3: building configuration "library"...
unit-threaded:property 2.0.3: building configuration "default"...
unit-threaded:runner 2.0.3: building configuration "library"...
subpackages/runner/source/unit_threaded/runner/factory.d(55,24): Error: template `std.conv.text` cannot deduce function from argument types `!()(string, const(TestData))`
/var/lib/buildkite-agent/builds/ci-agent-7d11ce47-aa1b-4308-a8a5-39b5bb0de700-2/dlang/phobos/build/distribution/bin/../imports/std/conv.d(4738,8):        Candidate is: `text(T...)(const(T) args)`
subpackages/runner/source/unit_threaded/runner/testcase.d(274,39): Error: template `std.conv.text` cannot deduce function from argument types `!()(string, string, string, const(TypeInfo), string, TypeInfo_Class)`
/var/lib/buildkite-agent/builds/ci-agent-7d11ce47-aa1b-4308-a8a5-39b5bb0de700-2/dlang/phobos/build/distribution/bin/../imports/std/conv.d(4738,8):        Candidate is: `text(T...)(const(T) args)`

[nordlow]

subpackages/runner/source/unit_threaded/runner/factory.d(55,24): Error: template std.conv.text cannot deduce function from argument types !()(string, const(TestData))

I can't make sense of why this fails.

This passes when I change

const(T) args

to

const T args

Unfortunately using const T args makes make -f posix.mak unittest fail in several places because std.format doesn't yet correctly handles ranges passed by const. We could define an overload that passes only non-ranges by const. Both cases reduce template bloat in my measurements.

Update: This describes the reduced cases:

class C {}
struct S 
{
    C c; // all calls pass when we qualify this as const
}

void test() {
    S m;
    const S c;
    void f(T...)(const(T) t)
    {
    }
    static assert( __traits(compiles, { f(m, m); }));
    static assert(!__traits(compiles, { f(m, c); }));
    static assert(!__traits(compiles, { f(c, m); }));
    static assert(!__traits(compiles, { f(c, c); }));
}

I'm surprised this isn't covered by Phobos unittests. Is this a compiler bug, @maxhaton @andralex?

[0xEAB]

Unfortunately using const T args makes make -f posix.mak unittest fail in several places because std.format doesn't yet correctly handles ranges passed by const. We could define an overload that passes only non-ranges by const. Both cases reduce template bloat in my measurements.

Indeed.

static struct Range
{
	int counter = 0;

@safe pure nothrow @nogc:
	bool empty() const => (counter <= 0);
	int front() const => counter;
	void popFront() { --counter; }
}

auto m = Range(2);

… would get printed as const(Range)(2) instead of [2, 1].
And I don’t think we can blame the library; a const range that you can’t pop-front is a dead end – kinda.

[0xEAB]

CI failures are expected; this patch is still flawed.

[pbackus]

This caused regressions when it was done in std.format (PR #8249), and it will cause regressions here too. This PR must not be merged.

[0xEAB]

Having had a glimpse at https://github.com/dlang/phobos/pull/8591/files#diff-0cefbc614b4b0ed8ef2e594905dddb131963e859be1af0068c9bb5b7b129ba89, I suppose this won’t be solvable realistically – right?

[pbackus]

No, this is not solvable—not even in principle.

In general, if a use passes a value of an arbitrary type into generic code, and the generic code wants to use that value to call other functions/methods, it must preserve the exact type (including qualifiers) of the value in order to call the correct overload(s).

[0xEAB]

Phantom-zoning this.
If someone disagrees and considers this salvageable, feel free to re-open (and tag accordingly).