On 11/25/16 11:47 AM, Jonathan M Davis via Digitalmars-d wrote:
On Friday, November 25, 2016 10:46:15 Steven Schveighoffer via Digitalmars-d
wrote:
On 11/25/16 8:24 AM, Jonathan M Davis via Digitalmars-d wrote:
I would point out that technically, that breaks the range API.
isInputRange requires that popFront be callable with parens, but it
does not require that it be callable without parens. So, someone could
define popFront as a public member variable with an overloaded opCall.
That would not compile if it were used with code that called popFront
without parens even though it would compile with isInputRange.
This is a misunderstanding. The missing parens is for *usage* of the
range, not *definition* of the range. It won't affect isInputRange at all.
It's not a misunderstanding.
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
}));
}
calls popFront with parens. That means that it's perfectly legal per
isInputRange to define popFront such that it's a callable that does _not_
work with optional parens. So, if it were a member variable that defined
opCall or was a delegate, then to use it, the parens are required. That
means that I could define a range that passes isInputRange but does not work
with code that called popFront without parens. As isInputRange is currently
defined, it's perfectly legal.
It's perfectly legal to make a popFront that destroys your entire
program. Or that doesn't actually pop the front (see old generate()
function). So what? I can't see the point of going out of your way to
make a popFront member that supports opCall, when you can use a function.
Note: there are cases out there where popFront is called without
parentheses. It has never broken any code. This should be a hint that
what you are concerned about doesn't happen in practice.
-Steve
