isInputRange copied verbatim produces a different result than isInputRange from std.range

[Jonathan M Davis]

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