www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - how to define my own traits

reply XavierAP <n3minis-git yahoo.es> writes:
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.
Mar 26 2017
next sibling parent reply Moritz Maxeiner <moritz ucworks.org> writes:
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
Mar 26 2017
parent XavierAP <n3minis-git yahoo.es> writes:
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
Mar 27 2017
prev sibling parent reply Gary Willoughby <dev nomad.so> writes:
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
Mar 27 2017
parent reply XavierAP <n3minis-git yahoo.es> writes:
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...
Mar 27 2017
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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...
Mar 27 2017