std.parallelism changes done

dsimcha dsimcha at yahoo.com
Thu Mar 24 17:49:19 PDT 2011


On 3/24/2011 1:34 PM, spir wrote:
> On 03/24/2011 05:32 PM, bearophile wrote:
>>> I tried to keep it as consistent as possible with std.algorithm.
>> OK. Then the question is why std.algorithm uses normal strings instead
>> of q{} ones.
>>
>> And regarding consistency with std.algorithm, a more important factor
>> is that std.algorithm.map is lazy, while you have a eager map, and the
>> lazy version has lazy in the name, so the names are kind of opposite
>> of std.algorithm.
>
> I agree there should be a consistent naming scheme here. Aligning with
> std.algo to consider lazy as standard sounds good. (Better than the
> opposite anyway, maybe not as good as explicite for both cases --but
> this is a lost fight ;-)
>
> Denis

Thanks for the suggestions, everyone.  I've made all the changes 
suggested today, plus a few others:

1.  map -> amap (eager), lazyMap -> map (lazy)

2.  isPure is no longer documented, since it was never meant to be part 
of the public API.

3.  I put TaskPool.join() in a version(none) statement and removed all 
references to it from the documentation.  If anyone has a compelling 
reason why this is useful (preferably with a good, short example), I'll 
add it back.  Otherwise, it's gone, since IMHO it's an evolutionary 
artifact that makes sense in theory but that I can't think of a use for 
anymore in practice.

4.  After some prodding and thinking I've finally been convinced that 
task() should just return auto.  I thought documenting the return types 
explicitly would clarify things, but from the questions I've gotten 
about it, it seems to obfuscate more than it clarifies.

5.  This one should have been done a long time ago:  amap() now accepts 
explicit buffers with element types that are implicit conversion targets 
of the return type of the map function.


More information about the Digitalmars-d mailing list