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
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
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
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
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
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