Kagamin:

> Don't even think, ranges are not better.

I am thinking about syntax sugar that the compiler uses to create a input/forward range similar to this:

http://forum.dlang.org/post/awabysprjjnrxrhgqyee@forum.dlang.org

Bye,
bearophile

On Wednesday, 19 March 2014 at 10:41:59 UTC, bearophile wrote:
> Kagamin:
>> Don't even think, ranges are not better.
>
> I am thinking about syntax sugar that the compiler uses to create a input/forward range similar to this:
>
> http://forum.dlang.org/post/awabysprjjnrxrhgqyee@forum.dlang.org

There is, however, a fundamental difference between ranges and opApply: Ranges use external iteration, whereas in opApply, it is the collection object that controls how iteration is performed. Features like transparent parallelization in std.parallelism would not be possible without this.

David

On Sunday, 16 March 2014 at 04:08:15 UTC, Andrei Alexandrescu wrote:
> D1's approach to multithreading was wanting. D2 executed a big departure from that with the shared qualifier and the default-thread-local approach to data.
>
> We think this is a win, but D2 inherited a lot of D1's thread-related behavior by default, and some of the rules introduced by TDPL (http://goo.gl/9gtH0g) remained in the "I have a dream" stage.
>
> Fixing that has not gained focus until recently, when e.g. https://github.com/D-Programming-Language/dmd/pull/3067

What was the final conclusion to this? Should the PR be reopened or the issue finally closed?