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