I've looked into Phobos to emulate it when defining my own trait template, and when I see this:

module std.range.primitives;
// ...
template isInputRange(R)
{
    enum bool isInputRange = is(typeof(
    (inout int = 0)
    {
        R r = R.init;     // can define a range object
        if (r.empty) {}   // can test for empty
        r.popFront;       // can invoke popFront()
        auto h = r.front; // can get the front of the range
    }));

I wonder, why that unused parameter (inout int = 0)?
In my project () { /* ... */ } works the same for a custom trait.

On Sunday, 26 March 2017 at 23:25:49 UTC, XavierAP wrote:
> I've looked into Phobos to emulate it when defining my own trait template, and when I see this:
>
> module std.range.primitives;
> // ...
> template isInputRange(R)
> {
>     enum bool isInputRange = is(typeof(
>     (inout int = 0)
>     {
>         R r = R.init;     // can define a range object
>         if (r.empty) {}   // can test for empty
>         r.popFront;       // can invoke popFront()
>         auto h = r.front; // can get the front of the range
>     }));
>
> I wonder, why that unused parameter (inout int = 0)?

`git blame` is your friend. It's all documented in the commit logs:
The original version does not have that parameter [1]. Then, to fix using isInputRange on an inout argument [2] a dummy parameter was introduced to force the delegate inside isInputRange to be typed as inout as well [3].
Later, the dummy parameter's name was dropped [4].

> In my project () { /* ... */ } works the same for a custom trait.

Have you tried it without the dummy parameter on the example given in the bug report [2]?

[1] https://github.com/dlang/phobos/commit/49f646271bf6c843fcdd90249baa875bf43be0a1#diff-b7fc67b6fcb7d1a521918d06ffe03587R50
[2] https://issues.dlang.org/show_bug.cgi?id=7824
[3] https://github.com/dlang/phobos/commit/ed00f6c28c602bd5c3b197e555c44d3b53ef76ba
[4] https://github.com/dlang/phobos/commit/db1d909d7adb1b28ec0ba1895f56da0cc01a937b

On Monday, 27 March 2017 at 00:49:14 UTC, Moritz Maxeiner wrote:
>
> Have you tried it without the dummy parameter on the example given in the bug report [2]?

I see, thanks for finding it! Looks a bit hacky but I can live with it.

Indeed if I remove the argument from Phobos, Martin's example breaks again.

Incidentally, everything keeps working if I qualify the function literal as
(inout int = 0) pure

On Sunday, 26 March 2017 at 23:25:49 UTC, XavierAP wrote:
> I've looked into Phobos to emulate it when defining my own trait template, and when I see this:
>
> module std.range.primitives;
> // ...
> template isInputRange(R)
> {
>     enum bool isInputRange = is(typeof(
>     (inout int = 0)
>     {
>         R r = R.init;     // can define a range object
>         if (r.empty) {}   // can test for empty
>         r.popFront;       // can invoke popFront()
>         auto h = r.front; // can get the front of the range
>     }));
>
> I wonder, why that unused parameter (inout int = 0)?
> In my project () { /* ... */ } works the same for a custom trait.

Even Andrei was baffled:

http://forum.dlang.org/thread/nepm2k$311l$1@digitalmars.com

On Monday, 27 March 2017 at 16:28:13 UTC, Gary Willoughby wrote:
>
> Even Andrei was baffled:
>
> http://forum.dlang.org/thread/nepm2k$311l$1@digitalmars.com

I see... And Walter went further and reported it as a DMD bug (still open clearly).

It's what I mean. This strange behavior is more typical of C++, in D this is a rare corner case, but I can sympathize if Andrei and Walter don't want to accumulate issues like this one in the language, and on top of that fill the standard library and user code with this kind of workarounds.

First the solution is a hack, but ideally it wouldn't be needed, the original code should have worked with inout ranges all the same. So ideally DMD should be fixed to make the hack unnecessary. Andrei's proposal of deprecating inout entirely is also consistent at the expense of losing a feature.

When I first read about inout as a device to obviate code duplication typical in C++ const ref overloads, I liked it but I assumed it was implemented by lowering it into the actual duplicate overloads. Though I'm not even sure right now if such overloading is allowed in D.

I haven't tried if this happens with other compilers than DMD...

On Monday, 27 March 2017 at 21:18:31 UTC, XavierAP wrote:
> When I first read about inout as a device to obviate code duplication typical in C++ const ref overloads, I liked it but I assumed it was implemented by lowering it into the actual duplicate overloads. Though I'm not even sure right now if such overloading is allowed in D.
>
> I haven't tried if this happens with other compilers than DMD...

Well given that dmd, ldc and gdc all share the same front end...