Parallel execution of unittests

[Jason Spencer via Digitalmars-d]

On Friday, 2 May 2014 at 14:59:50 UTC, Andrei Alexandrescu wrote:
> I need to make an amend to this because indeed it's more than 2 
> std deviations away from niceness: I have a long history of 
> ideas with a poor complexity/usefulness ratio, and I now wish 
> I'd received such a jolt. -- Andrei

I appreciate that, and can accept it in the spirit of mentoring 
and helpfulness.  What might work even better for me, though, is 
to forego the assumption that I need such a jolt or that you are 
the person, in this forum at least, to provide it and simply 
address the merits or lack thereof of the suggestion as made.

If we can't agree that a method, direct or indirect, to control 
the order of UTs is appropriate, then we should opt for the 
status quo.  By my reading of this thread, that leaves us with no 
consensus that UTs MUST be order-independent, but that being able 
to parallelize is a good thing.  It seems we can:

  1. leave defaults as they are and make parallelization an 
option, or
  2. make it the language model and allow people to dissent with 
an option

I can agree with Andre that you'd rather have a solid, 
well-defined language that works in most cases without too many 
buttons, switches, and levers.  I'm just not sure that jives with 
"easiest is safest" and "don't impose a model, provide a tool."  
To me, improving the performance of a non-performance-critical 
aspect does not weigh enough to counterbalance a safety risk and 
model imposition.  How about others?

Test names seems pretty much agreed to.  I think the idea of 
making everything available to the druntime would let pretty much 
anyone do what they need.