On Thursday, 1 September 2016 at 16:38:15 UTC, Dicebot wrote:
> On 09/01/2016 07:17 PM, ZombineDev wrote:
>> On Thursday, 1 September 2016 at 12:06:21 UTC, Dicebot wrote:
>>> On 08/31/2016 01:01 PM, Atila Neves wrote:
>>>> And never mind that any such low level library would suffer from the same problem unit-threaded did until dub fixed it: D can't reflect on packages so a program must be written that explicitly lists all modules that need to be looked at.
>>>
>>> I don't even think fixing package reflection would truly help here because there exist legit D projects that don't transitively import all modules from `main` and recursive compile-time visiting of all symbols would miss them.
>>>
>>>> [snip]
>> 
>> Not a problem, since you can do things like this:
>
> It is exactly _THE_ problem. You can't have the imaginary test runner to reliably find all tests automatically, at least all compiled modules have to be listed explicitly. This is not good, thus I am inclined to call extending RTTI an only viable long-term solution.

Ooh, I thought that by "fixing package reflection" Atila meant the ability to get a list of all modules/packages that the compiler knows about, assuming an all at once compilation. For things like dynamic libraries and incremental compilation, there's obviously no other way than RTTI. But for many use-cases CT reflection should be enough.

On 2016-09-01 14:02, Dicebot wrote:

> What would be different? List of unit test blocks available in the program?

How the unit tests are written and collected.

unittest { assert(true); }

class FooTest : Test
{
    void testFoo() { assert(true); }
}

describe("foo", {
    it("does something", {
        assert(true);
    });
});

-- 
/Jacob Carlborg

On Friday, 2 September 2016 at 19:26:41 UTC, Jacob Carlborg wrote:
> On 2016-09-01 14:02, Dicebot wrote:
>
>> What would be different? List of unit test blocks available in the program?
>
> How the unit tests are written and collected.
>
> unittest { assert(true); }
>
> class FooTest : Test
> {
>     void testFoo() { assert(true); }
> }
>
> describe("foo", {
>     it("does something", {
>         assert(true);
>     });
> });

Then we perfectly understand each other and I will vote against introducing any other way/syntax for writing _unit_ tests in D with all my passion.

On 2016-09-02 21:52, Dicebot wrote:

> Then we perfectly understand each other and I will vote against
> introducing any other way/syntax for writing _unit_ tests in D with all
> my passion.

This discussion is just going in circles, meeting adjourned.

-- 
/Jacob Carlborg