On 25.11.2016 17:38, Kagamin wrote:
> On Friday, 25 November 2016 at 11:10:44 UTC, Timon Gehr wrote:
>> You can just as easily edit the while condition. I use it because
>> "unconditional loop" is less silly than "loop until true is false".
>
> Unconditional loop can be implemented in 3 possible ways :)
> 1. skip it entirely: since there's no condition to check, can't decide
> if should enter at all
> 2. run once: since there's no condition to check, can't decide if should
> repeat - becomes just an unconditional block statement
> 3. infinite loop as if the condition is always true - until it's false

Grab a dictionary.

On 11/24/2016 05:09 PM, Dennis Ritchie wrote:
> On Thursday, 24 November 2016 at 22:04:00 UTC, LiNbO3 wrote:
>> As you can see [1] the `while (true)` is lowered into `for (;true;)`
>> so it's all about what construct pleases you the most.
>>
>> [1]
>> https://github.com/dlang/dmd/blob/cd451ceae40d04f7371e46df1c955fd914f3085f/src/statementsem.d#L357
>>
>
> OK, thanks.
>
> The next question is:
> What principles guided when choosing between `for (;;) { ... }` and
> `while (true) { ... }` ?

Personal preference. Nothing more. Programmers have far better things to do that fret over the relative merits of two identical constructs that have no relative (de)merits over each other.

On Thu, Dec 01, 2016 at 11:23:26AM -0500, Nick Sabalausky via Digitalmars-d wrote:
> On 11/24/2016 05:09 PM, Dennis Ritchie wrote:
[...]
> > The next question is:
> > What principles guided when choosing between `for (;;) { ... }` and
> > `while (true) { ... }` ?
> 
> Personal preference. Nothing more. Programmers have far better things to do that fret over the relative merits of two identical constructs that have no relative (de)merits over each other.

Far better things?  You mean, like having endless discussions about a controversial D topic on this forum while procrastinating on the actual writing of code?  Yeah, I can see that.  :-P


T

-- 
It is of the new things that men tire --- of fashions and proposals and improvements and change. It is the old things that startle and intoxicate. It is the old things that are young. -- G.K. Chesterton

On Friday, 25 November 2016 at 15:29:31 UTC, Adam D. Ruppe wrote:
> 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.

This causes a world of pain when you want to pass functions around. Nothing gets my blood pressure up like the following code:

https://forum.dlang.org/post/piktfrtpltmjvjmedspr@forum.dlang.org

On Thursday, December 01, 2016 19:25:27 Meta via Digitalmars-d wrote:
> On Friday, 25 November 2016 at 15:29:31 UTC, Adam D. Ruppe wrote:
> > 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.
>
> This causes a world of pain when you want to pass functions around. Nothing gets my blood pressure up like the following code:
>
> https://forum.dlang.org/post/piktfrtpltmjvjmedspr@forum.dlang.org

I think that having optional parens in D was a mistake, and your situation there is an example of why it can be a big problem (the problems caused by being lax with syntax in generic code is another). However, the shipped has long since sailed on that one. It's too popular and too widely used to change at this point. And while I completely agree that allowing optional parens causes problems, it's also true that a lot of code is able to use it without difficulties, and many folks like it, particularly when they have to use parens for template arguments in UFCS call chains.

- Jonathan M Davis