April 29, 2016
On 4/28/2016 11:22 PM, Seb wrote:
> `foreach (i; 0..5)` seems to cover 95% of my for uses and it looks a lot
> cleaner. I am actually pretty happy that D has this!

foreach neatly eliminates most fencepost bugs.
April 29, 2016
On Friday, 29 April 2016 at 06:27:07 UTC, Jacob Carlborg wrote:
> In an ideal world the language would support trailing delegate syntax allowing this to work without any language support:
>
> forever {
> }
>
> Translated to:
>
> forever({
>
> });

Or maybe with macros supporting a trailing statement as the last argument:

macro forever($(Statement st));

$forever {
}

That way it's clearer that magic is happening, but also macros are by definition inlined. It also doesn't need braces for a single statement.

A complication with the delegate way is break/continue/return in the statement block, but I suppose it already works for opApply.

April 29, 2016
On Thursday, 28 April 2016 at 22:37:41 UTC, H. S. Teoh wrote:
> I find for(;;) far more logical than other vacuous workarounds like
> while(1) or while(true).

It's only because of C that all the for arguments can be left out, I'd rather have:

while {...}

I.e. it defaults to true. 'A while' is an interval of time, 'for' isn't.
April 29, 2016
On 29.04.2016 08:23, Jacob Carlborg wrote:
> foreach (i; 0 .. 5)

Yeah, but that's special syntax, not a range.
April 29, 2016
I think Swift is not yet stable. So if you want to use it you have to deal with language changes (D2 is stable).

In a modern language ++ and -- are OK only if they return void. Otherwise they are bug-prone and allow people to write less readable code.

C for() loops are powerful, but a bit too much bug prone and they encourage too much compressed code. Better to push reasonable coding standards inside the language itself.

Only const function arguments looks a bit excessive in defulting-to-const language, but I think it's acceptable if you have a way to make them mutable.

It seems Swift is copying several things from Rust. Perhaps Swift is going to become more popular than Rust (because Rust is more bondage&discipline, less handy because of manual memory management, more fussy, and usually fitter for system coding, unlike Swift that is more general purpose, on the other hand Rust is a bit more free than Swift now).

Bear hugs,
bearophile
April 29, 2016
On Friday, 29 April 2016 at 03:44:47 UTC, Nick Sabalausky wrote:
>
> Not surprised. Removing features is all the rage in the software world these days. This is one fad I can't wait to see die. Hopefully this one won't drag on as ridiculously log as pants-sagging did, but I'm not holding my breath.
>
> I say forget playing the "fire and motion" game. Just avoid the big five "our way-of-the-week or the highway" trend-factories (Google, Apple, Mozilla, Microsoft and Gnome) and everything should be (relatively) fine.

Actually, I did a bit of Java 8 programming recently and although I would complain about Java developing ridiculously slowly as a language (e.g. lambda support), I found that it is refreshingly conservative :-) Yes, there are loops, semicolons and operators, just like granny used to make them!

I'm glad Steve posted this here, because whenever a new fancy "must have" language is promoted, my attitude is: lay back, relax and watch it calmly. First Go and Rust, now Swift. We'll see. So far D has served me well.
May 02, 2016
On 29/04/16 14:24, ag0aep6g wrote:

> Yeah, but that's special syntax, not a range.

Does it matter? I thought the idea was to get the same behavior not explicitly a range.

-- 
/Jacob Carlborg
May 02, 2016
On 29/04/16 14:06, Nick Treleaven wrote:

> Or maybe with macros supporting a trailing statement as the last argument:
>
> macro forever($(Statement st));
>
> $forever {
> }

I tried to be a bit conservative, I don't mind macros :)

-- 
/Jacob Carlborg
May 02, 2016
On Friday, 29 April 2016 at 12:06:40 UTC, Nick Treleaven wrote:
> A complication with the delegate way is break/continue/return in the statement block, but I suppose it already works for opApply.

I'm curious: what does this actually lower to when compiling?
May 02, 2016
On 02.05.2016 09:45, Jacob Carlborg wrote:
> Does it matter? I thought the idea was to get the same behavior not
> explicitly a range.

default0 said that D's ranges would be more awkward than a for loop. I think D's iota is fine.

D's special syntax is even nicer, but it's a language thing. And apparently Swift is cutting down on syntax, not adding. Something like iota is probably doable in a library. I don't know Swift, though.