Really fix Issue 16478 - Don't allow to!T() in constraint

[ntrel]

• Use specialization to prefer to!S when S is a static array.

(For background, see #4898 (comment))

Ping @schveiguy.

[dlang-bot]

Fix	Bugzilla	Description
✓	16478	Don't allow to!T() in constraint

[schveiguy]

I don't think this will work, because constraints aren't considered specialization.

int[1] arr;
to!string(arr); // ambiguity error

What you need is something like:

if(Args.length > 1 || (Args.length == 1 && !isStaticArray!(Args[0])))

Alternatively, to can require a parameter like isRawStaticArray did:

auto to(Val, Args...)(Val v, Args args) if(!isStaticArray!Val)
{
    return toImpl!T(v, args);
}

[schveiguy]

Hm... it does work, but I don't understand why. I'm sure I've had to deal with this not being a specialization. I also can't find the rule that says why this is a specialization. But it seems to compile fine.

[ntrel]

    T to(A...)(A args)
        if (A.length > 0);
    T to(S)(ref S arg)
        if (isStaticArray!S);

I think it works like this. When one argument is supplied to to, A.length is 1, but due to specialization of to(S) not being variadic, to(S) is preferred if its constraint passes. Otherwise, the only option is to(A). So static arrays instantiate to(S), everything else, to(A).

[schveiguy]

Is that rule outlined in the spec somewhere?

[ntrel]

Not sure. Although the constraints page seems to support this - right at the end (under Overloading based on Constraints) it shows:

void foo(T, int N)()        if (N & 1) { ... } // A
void foo(T : int, int N)()  if (N > 3) { ... } // B
...
foo!(int, 7)();   // picks B, more specialized
foo!(int, 1)();   // picks A, as it fails B's constraint

[schveiguy]

But that is specialization as I understand it -- a colon with a specification is a specialization. See here: https://dlang.org/spec/template.html#parameters_specialization

I can't find the rule that says that individual type parameters are considered before variadic ones.

[schveiguy]

Regarding the PR, I think it's fine as long as this rule is correct and understood. I just don't know if the current behavior is what is intended.

[schveiguy]

Found the answer (@aG0aep6G on forums) https://dlang.org/spec/template.html#variadic_template_specialization

[schveiguy]

Lgtm

[schveiguy]

@CyberShadow why the failure?

[CyberShadow]

Hrm, the heuristic for the dlang.org makefile's iffy LATEST feature failed. We really should get rid of it.

Pushed a fix and queued PRs for retesting, hopefully should be fixed now. May need a commit to master to seed the cache.

[schveiguy]

Auto-merge toggled on

[schveiguy]

@CyberShadow thanks.