Re: how to define my own traits

2017-03-27 Thread Nicholas Wilson via Digitalmars-d-learn

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



Re: how to define my own traits

2017-03-27 Thread XavierAP via Digitalmars-d-learn

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


Re: how to define my own traits

2017-03-27 Thread Gary Willoughby via Digitalmars-d-learn

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


Re: how to define my own traits

2017-03-27 Thread XavierAP via Digitalmars-d-learn

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


Re: how to define my own traits

2017-03-26 Thread Moritz Maxeiner via Digitalmars-d-learn

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


how to define my own traits

2017-03-26 Thread XavierAP via Digitalmars-d-learn
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.