OT: for (;;) {} vs while (true) {}

[Steven Schveighoffer via Digitalmars-d]

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