On Monday, 26 October 2015 at 21:27:37 UTC, Walter Bright wrote:
and we're not supposed to break existing code. But the
alternative, which is redoing every template that accepts an
InputRange, seems an awfully heavy burden. Even if we do this
change pervasively in Phobos, how does that help anyone else
who uses InputRanges?
Tl,dr: the alias this in DirEntry is an abusive bad practice,
and should never have happened.
I agree that for DirEntry it may have been dubious practice, but
it is a problem in general.
Since nobody else is making the case for the elephant in the
room, I'll make the case for changing IFTI to consider AliasThis.
Please excuse the informal and clumsy presentation.
Let's use isDir as our function template and DirEntry as the
offending subtype:
---
@property bool isDir(R)(R name) if (isInputRange!R &&
isSomeChar!(ElementEncodingType!R));
foreach(f; dirEntries("/", "*", SpanMode.shallow, false))
if(isDir(f)) // Error
...
---
Errors with: "Error: template std.file.isDir cannot deduce
function from argument types !()(DirEntry)"
IFTI is in effect when calling isDir: isDir!DirEntry is
attempted, which doesn't match the template constraints.
However, explicitly instantiating isDir to receive the supertype
works:
---
foreach(f; dirEntries("/", "*", SpanMode.shallow, false))
if(isDir!string(f)) // OK
...
---
This gives us the same behaviour we had before templatization:
the argument is implicitly converted to the supertype at the
call-site.
An IFTI rule supporting this doesn't have to be complicated
AFAICS: if there are no matches for exact type T, recursively try
supertypes of T until first match. If no matches, error out. If
more than one match at one level of AliasThis (hypothetical
multiple AliasThis), error out.
Interestingly, a side effect would be that it gives more
importance to template constraints. I don't know if that's a good
or a bad thing.
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos
