Voting for std.experimental.testing

[Rikki Cattermole via Digitalmars-d]

On 12/10/15 3:39 PM, stewart wrote:
> On Thursday, 8 October 2015 at 08:21:58 UTC, Robert burner Schadek wrote:
>> This is the voting thread for inclusion of std.experimental.testing
>> into phobos.
>>
>> PR: https://github.com/D-Programming-Language/phobos/pull/3207
>> Dub: http://code.dlang.org/packages/unit-threaded
>> Doc: See CyberShadow/DAutoTest for up-to-date documentation build
>> Formal Review Thread:
>> http://forum.dlang.org/post/stbdckpfsysjtppldmry@forum.dlang.org
>> Previous Thread:
>> http://forum.dlang.org/post/uzocokshugchescbawlj@forum.dlang.org
>>
>> Please respond to this post with a comment starting with a single
>> "Yes"/"No" and optional explanation after that. Criteria you are
>> expected to evaluate as part of "Yes":
>>
>> - is this functionality needed in Phobos
>> - is basic design sound (some breaking changes are OK for
>> std.experimental but not full redesign)
>>
>> As usual, anyone can vote, but opinions of Phobos developers hold more
>> value.
>>
>> Voting ends in 2 weeks, on Oktober 22.
>
>
> No
>
> a) Doesn't add enough value; I feel DIP83 (and also DIP82) are more
> important and this library should wait then build on DIP83.
>
> b) There'd be more bang for buck if we had good backtrace support on all
> platforms when asserts fire.
>
> c) Implements orthogonal functionality, as per Rikki's comments,
> coupling a testing framework with implementation of coloured output and
> report generation. Pretty output should wait until available from other
> modules in Phobos.

That's not quite what I meant. It doesn't need to wait. As long as the 
implementation stays private and is not exposed in anyway, it is fine.
We can rewrite it to use new functionality of Phobos at a later point.
We just need to acknowledge that it will need to happen at this time.

> d) API is clunky because lower-level components are not available.
>
> e) Named unittests are nice but unless something like unittest(name) is
> accepted it isn't worth it.
>
> __FUNCITON__ already provides a UID that includes line number
> information, which is 100x more useful than a name made up by Joe
> Developer. If we get b) above then unittest names really become
> unnecessary IMO.
>
> bye,
> stew