[Issue 15027] rangified functions no longer work with alias this'ed strings (e.g. DirEntry)

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15027

Jakob Ovrum <jakobovrum at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakobovrum at gmail.com

--- Comment #19 from Jakob Ovrum <jakobovrum at gmail.com> ---
(In reply to Walter Bright from comment #5)
> So, the solution can only be one of:
> 1. DirEntry is an InputRange.
> 2. DirEntry is converted to an InputRange before passing to isDir().
> 
> The trouble with (1) is that DirEntry then becomes consumed, which would be
> surprising behavior.

When the range algorithm receives the range by value, then the DirEntry and its
member slice are copied and only this copy is consumed, so I'm not sure it
would be a big problem. It is essentially the same situation we have with other
range types.

However, from an encapsulation standpoint, DirEntry.name shouldn't be
externally modifiable even for a mutable DirEntry instance. At least I think
this is the conservative OOP angle.

One intrusive change could be to consider DirEntry a "container" of characters,
which presents a range interface with dirEntry[]. It's basically a
generalisation of what is going on now with the StringTypeOf changes. I agree
that this approach doesn't scale. It puts the onus of converting to range type
on the wrong side of the function call. The meat of the algorithm wants a
*range of characters*, and the ritual conversion to this range of characters is
just a triviality that has nothing to do with the algorithm.

What previously happened with passing DirEntry to string functions was that the
argument was converted to the character range supertype implicitly *at the
call-site*. So maybe simply what the right solution is, even if it's hard, is
to redesign IFTI to consider AliasThis.

--