On Friday, 25 November 2016 at 11:10:44 UTC, Timon Gehr wrote:
> On 25.11.2016 11:33, Claude wrote:
>> ...
>>
>> Between "for(;;)", "while(true)" and "do while(true)", I would use the
>> "while (true) { }" for pure readability and semantic reasons.
>> ...
>
> What semantic reasons?

In the general sense:

- While true (is always true), I loop.

Is more meaningful and conceptually easy then the empty for statement :

- For "empty initialization statement" until "I don't know (so forever by default)" and "not iterating", I loop.

>> I reckon "for(;;)" form is used for debug reasons (so you can easily
>> insert conditions to transform an infinite loop into a finite one).
>
> You can just as easily edit the while condition. I use it because "unconditional loop" is less silly than "loop until true is false".

I was just trying to explain why one would use for(;;) instead of while(true), you've got only one line to edit.

It's in same vein as using:

if (cond)
{

}

Sorry, I sent my post before finishing it, so...

It's in same vein as using:

if (cond)
{
  singleStatement;
}

instead of:

if (cond)
  singleStatement;

Because, you can more easily insert statements within the block (without having to navigate to different to insert the brackets).

On Friday, 25 November 2016 at 11:20:24 UTC, Jonathan M Davis wrote:
> Probably the complete lack of a condition to test in for(;;). I confess that I was shocked when I found out that it was legal to have a for loop without a condition. That seems like doing while() or if(), which makes no sense. So, I never use for(;;) and wish that it didn't exist, but it does, and some folks use it. So, I have to live with the possiblity of dealing with it when dealing with code written by other people. But I won't ever use it.

IMO, it is very convenient for system programming guru. It is believed that it came from the K&R.

For example, this option is definitely very convenient to use:
https://github.com/dlang/phobos/blob/master/std/algorithm/comparison.d#L591

On 11/25/2016 07:53 AM, Dennis Ritchie wrote:
> On Friday, 25 November 2016 at 11:20:24 UTC, Jonathan M Davis wrote:
>> Probably the complete lack of a condition to test in for(;;). I
>> confess that I was shocked when I found out that it was legal to have
>> a for loop without a condition. That seems like doing while() or if(),
>> which makes no sense. So, I never use for(;;) and wish that it didn't
>> exist, but it does, and some folks use it. So, I have to live with the
>> possiblity of dealing with it when dealing with code written by other
>> people. But I won't ever use it.
>
> IMO, it is very convenient for system programming guru. It is believed
> that it came from the K&R.
>
> For example, this option is definitely very convenient to use:
> https://github.com/dlang/phobos/blob/master/std/algorithm/comparison.d#L591

I like that function. If I were to review it now, I'd approve with these nits:

* drop the parens for popFront

* s/-cast(int)!r2.empty/-int(!r2.empty)/

* Merge with the cmp implementation for strings and simplify the constraint from

if (isInputRange!R1 && isInputRange!R2 && !(isSomeString!R1 && isSomeString!R2))

to

if (isInputRange!R1 && isInputRange!R2)

i.e. it's not relevant to users that the string version has a distinct implementation.

In fact I suggest someone implements this.


Andrei

On Friday, 25 November 2016 at 12:59:07 UTC, Andrei Alexandrescu wrote:
> i.e. it's not relevant to users that the string version has a distinct implementation.
>
> In fact I suggest someone implements this.

The problem is not the users, and the places where you will use your program. Because this code is easy to make a mistake that can lead to failure in the automated system.
Unfortunately, writing such code is not safe.

On Friday, November 25, 2016 07:59:07 Andrei Alexandrescu via Digitalmars-d wrote:
> On 11/25/2016 07:53 AM, Dennis Ritchie wrote:
> > https://github.com/dlang/phobos/blob/master/std/algorithm/comparison.d#L 591
> I like that function. If I were to review it now, I'd approve with these nits:
>
> * drop the parens for popFront

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.

Now, realistically, no one is going to do that, so it probably doesn't matter. But it seems to me that in general, when dealing with a trait like isInputRange which tests that a particular syntax is used, it's just safer to use that syntax rather than using parens where it doesn't or not using parens where it does.

- Jonathan M Davis

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.

We need to change the range API then. -- Andrei

On Friday, 25 November 2016 at 15:03:26 UTC, Andrei Alexandrescu wrote:
> We need to change the range API then. -- Andrei

That's absurd, popFront is in no way semantically a property, so it should not get @property.

It has been so many years of this being poorly defined. Let's just close the book and officially put the status quo on optional parenthesis in stone: they are optional on zero-argument calls, regardless of @property, and that isn't going to change.

Then this popFront question becomes moot.

On 11/25/16 8:24 AM, Jonathan M Davis via Digitalmars-d wrote:
> On Friday, November 25, 2016 07:59:07 Andrei Alexandrescu via Digitalmars-d
> wrote:
>> On 11/25/2016 07:53 AM, Dennis Ritchie wrote:
>>> https://github.com/dlang/phobos/blob/master/std/algorithm/comparison.d#L
>>> 591
>> I like that function. If I were to review it now, I'd approve with these
>> nits:
>>
>> * drop the parens for popFront
>
> 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.

This case you have of defining a popFront member variable with opCall -- don't do that, it will break things (I'm sure there are already many places where popFront is called without parens). I don't think that's a case that we need worry about.

-Steve.

On 11/25/16 10:29 AM, Adam D. Ruppe wrote:
> Let's just close the book and officially put the status quo on optional
> parenthesis in stone: they are optional on zero-argument calls,
> regardless of @property, and that isn't going to change.

Agreed. -- Andrei