www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - isInputRange copied verbatim produces a different result than

reply aliak <something something.com> writes:
Hi, I have a custom type D with front/popFront/empty implemented 
as free functions, but isInputRange returns false. I copied the 
implementation of isInputRange, and that custom implementation 
returns true... anyone know what's going on here?

===
import std.stdio, std.range, std.traits;

// Code copied veratim from:
// 
https://github.com/dlang/phobos/blob/v2.079.0/std/range/primitives.d#L164
enum bool isIR(R) =
     is(typeof(R.init) == R)
     && is(ReturnType!((R r) => r.empty) == bool)
     && is(typeof((return ref R r) => r.front))
     && !is(ReturnType!((R r) => r.front) == void)
     && is(typeof((R r) => r.popFront));

struct D {}

 property int front(D d) { return 2; }
 property bool empty(D d) { return false; }
void popFront(D d) {}

pragma(msg, isIR!D); // true
pragma(msg, isInputRange!D); // false ???

pragma(msg, is(typeof(D.init) == D)); // true
pragma(msg, is(ReturnType!((D r) => r.empty) == bool)); // true
pragma(msg, is(typeof((return ref D r) => r.front))); // true
pragma(msg, !is(ReturnType!((D r) => r.front) == void)); // true
pragma(msg, is(typeof((D r) => r.popFront))); // true

void main() {}
===

Thanks for any help!
- Ali
Mar 04 2018
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 4 March 2018 at 12:57:41 UTC, aliak wrote:

  property int front(D d) { return 2; }
  property bool empty(D d) { return false; }
 void popFront(D d) {}


Those functions are in scope for your function, but not inside 
std.range.

in other words std.range hasn't imported your module, so it can't 
see those three functions.
Mar 04 2018
next sibling parent aliak <something something.com> writes:
On Sunday, 4 March 2018 at 13:17:30 UTC, Adam D. Ruppe wrote:

 On Sunday, 4 March 2018 at 12:57:41 UTC, aliak wrote:

  property int front(D d) { return 2; }
  property bool empty(D d) { return false; }
 void popFront(D d) {}


 Those functions are in scope for your function, but not inside 
 std.range.

 in other words std.range hasn't imported your module, so it 
 can't see those three functions.


Ah, of course!
Thanks!
Mar 04 2018
prev sibling parent reply aliak <something something.com> writes:
On Sunday, 4 March 2018 at 13:17:30 UTC, Adam D. Ruppe wrote:

 On Sunday, 4 March 2018 at 12:57:41 UTC, aliak wrote:

  property int front(D d) { return 2; }
  property bool empty(D d) { return false; }
 void popFront(D d) {}


 Those functions are in scope for your function, but not inside 
 std.range.

 in other words std.range hasn't imported your module, so it 
 can't see those three functions.


wait a minute... so I can't use any std.range functions on a type 
if I add the range primitives as free functions? O.o
Mar 04 2018
parent reply ag0aep6g <anonymous example.com> writes:
On 03/04/2018 08:54 PM, aliak wrote:

 wait a minute... so I can't use any std.range functions on a type if I 
 add the range primitives as free functions? O.o


Yes. In other words: You can't implement range primitives as free 
functions. Because std.range (and std.algorithm, etc.) doesn't know 
about them.
Mar 04 2018
parent reply arturg <var.spool.mail700 gmail.com> writes:
On Sunday, 4 March 2018 at 19:58:14 UTC, ag0aep6g wrote:

 On 03/04/2018 08:54 PM, aliak wrote:

 wait a minute... so I can't use any std.range functions on a 
 type if I add the range primitives as free functions? O.o


 Yes. In other words: You can't implement range primitives as 
 free functions. Because std.range (and std.algorithm, etc.) 
 doesn't know about them.


isn't this what DIP 1005 tried to solve?

as long as you dont want to role your own test its not possible.

module moda;

struct Imports
{
     string importString;
}

template isInputRange(R)
{
     import std.traits: hasUDA, getUDAs, ReturnType;

     static if(hasUDA!(R, Imports))
     static foreach(u; getUDAs!(R, Imports))
     mixin(u.importString);

     enum bool isInputRange =
         is(typeof(R.init) == R)
         && is(ReturnType!((R r) => r.empty) == bool)
         && is(typeof((return ref R r) => r.front))
         && !is(ReturnType!((R r) => r.front) == void)
         && is(typeof((R r) => r.popFront));
}

-----

module test;

import std.stdio;
import moda;

void main(string[] args)
{
     isInputRange!Type.writeln;
}

bool empty(Type t) { return true; }
int front(Type t) { return 42; }
void popFront(Type t) {}

 Imports("import test: empty, front, popFront;")
struct Type
{
}
Mar 04 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, March 04, 2018 21:03:23 arturg via Digitalmars-d-learn wrote:

 On Sunday, 4 March 2018 at 19:58:14 UTC, ag0aep6g wrote:

 On 03/04/2018 08:54 PM, aliak wrote:

 wait a minute... so I can't use any std.range functions on a
 type if I add the range primitives as free functions? O.o


 Yes. In other words: You can't implement range primitives as
 free functions. Because std.range (and std.algorithm, etc.)
 doesn't know about them.


 isn't this what DIP 1005 tried to solve?


No. What DIP 1005 was trying to solve was avoiding having to have imports
used by your function signature or template constraint on top-level
constructs be available to the entire module. It wanted the imports to only
kick in when the symbol that needed them was used. So, it would be possible
to then import isInputRange as part of a function that needed it in its
template constraint without the rest of the module seeing that import,
whereas right now, such an import would have to be at the top level and
would affect the entire module. DIP 1005 didn't do anything to make it so
that other modules could see what you imported, and I doubt that any DIP
ever would, because if that were possible, it would cause function
hijacking, because you could force other modules to import what you wanted
instead of what the person who wrote them imported.

- Jonathan M Davis
Mar 04 2018
parent arturg <var.spool.mail700 gmail.com> writes:
On Sunday, 4 March 2018 at 21:47:43 UTC, Jonathan M Davis wrote:

 On Sunday, March 04, 2018 21:03:23 arturg via 
 Digitalmars-d-learn wrote:

 isn't this what DIP 1005 tried to solve?


 No. What DIP 1005 was trying to solve was avoiding having to 
 have imports used by your function signature or template 
 constraint on top-level constructs be available to the entire 
 module. It wanted the imports to only kick in when the symbol 
 that needed them was used. So, it would be possible to then 
 import isInputRange as part of a function that needed it in its 
 template constraint without the rest of the module seeing that 
 import, whereas right now, such an import would have to be at 
 the top level and would affect the entire module. DIP 1005 
 didn't do anything to make it so that other modules could see 
 what you imported, and I doubt that any DIP ever would, because 
 if that were possible, it would cause function hijacking, 
 because you could force other modules to import what you wanted 
 instead of what the person who wrote them imported.

 - Jonathan M Davis


hm yeah i hoped that dip 1005 would be introspectable so you 
could use it instead of relying on udas.
Mar 04 2018