February 27, 2013
On 2/27/2013 4:19 AM, Jacob Carlborg wrote:
> I think that is one of the problems with unit tests in D. I don't know how to
> run them.

Compile with -unittest and then run.


> * How do I run all the unit test in all of my files?

Compile all files with -unittest and then run the program.


> * How do I run a single test?
> * How do I run a subset of the tests?

Compile only the modules you want to run the unittests on with -unittest.

February 27, 2013
On 2013-02-27 14:29, Andrei Alexandrescu wrote:

> Four years ago I would've entirely agreed. But right now it's an odd
> comment to make seeing as we're discussing all major decisions in this
> group and we're switching full-bore to DIPs.

The "alias this" syntax the foobar mentioned was removed under the radar and only discussed in a pull request.

-- 
/Jacob Carlborg
February 27, 2013
On 2013-02-27 20:23, Walter Bright wrote:
> On 2/27/2013 4:19 AM, Jacob Carlborg wrote:
>> I think that is one of the problems with unit tests in D. I don't know
>> how to
>> run them.
>
> Compile with -unittest and then run.
>
>
>> * How do I run all the unit test in all of my files?
>
> Compile all files with -unittest and then run the program.
>
>
>> * How do I run a single test?
>> * How do I run a subset of the tests?
>
> Compile only the modules you want to run the unittests on with -unittest.

I don't. I have a script that handles this. Someone else might have another script doing things differently. This is the problem.

-- 
/Jacob Carlborg
February 27, 2013
On 2/27/13 3:16 PM, Jacob Carlborg wrote:
> On 2013-02-27 14:29, Andrei Alexandrescu wrote:
>
>> Four years ago I would've entirely agreed. But right now it's an odd
>> comment to make seeing as we're discussing all major decisions in this
>> group and we're switching full-bore to DIPs.
>
> The "alias this" syntax the foobar mentioned was removed under the radar
> and only discussed in a pull request.

I agree we were sloppy on that. Kenji was feeling strong about and Walter and I didn't have particular objections, so we gave him green light. In the process we neglected backward compatibility.

Andrei


February 27, 2013
On Wed, 27 Feb 2013 11:42:53 +0100
Jacob Carlborg <doob@me.com> wrote:

> On 2013-02-27 00:37, Andrei Alexandrescu wrote:
> 
> > Agreed, but it does happen often that a language feature is later superseded by a generalization thereof.
> 
> In this case it would be two features:
> 
> 1. Allow to run arbitrary code at top level
> 2. Allow to pass a delegate to a function after the parameter list
> 
> void unittest (void delegate () dg)
> 
> unittest {
>      assert(true);
> }
> 
> Would be lowered to:
> 
> unittest({
>      assert(true);
> });
> 
> Then we also can easily support named unit tests:
> 
> void unittest (string name, void delegate () dg)
> 
> unittest("foo") {
>      assert(true);
> }
> 
> Would be lowered to:
> 
> unittest("foo", {
>      assert(true);
> });
> 
> I think it would be nice if D could get better at declarative programming.
> 

I like that, but "run arbitrary code at top level" may be a bit of a problem because it conflicts with allowing forward references.

Ie, for example:

    void foo() { bar(); }
    void bar() { i = 3; }
    int i;

vs:

    void main() {
        void foo() { bar(); }
        void bar() { i = 3; }
        int i;
    }


The first one works, but the second doesn't. And my understanding is that the second one not working is a deliberate thing related to not being in a declaration-only context.

February 27, 2013
On 2/27/2013 2:55 PM, Nick Sabalausky wrote:
> I like that, but "run arbitrary code at top level" may be a bit of a
> problem because it conflicts with allowing forward references.
>
> Ie, for example:
>
>      void foo() { bar(); }
>      void bar() { i = 3; }
>      int i;
>
> vs:
>
>      void main() {
>          void foo() { bar(); }
>          void bar() { i = 3; }
>          int i;
>      }
>
>
> The first one works, but the second doesn't. And my understanding is
> that the second one not working is a deliberate thing related to
> not being in a declaration-only context.

It's a little more than that. People have a natural view of function bodies as executing top down. Functions also tend to be simple enough that this makes sense. People have a natural view outside functions as everything happening in parallel.
February 28, 2013
On Wednesday, 27 February 2013 at 23:34:42 UTC, Walter Bright wrote:
> On 2/27/2013 2:55 PM, Nick Sabalausky wrote:
>> I like that, but "run arbitrary code at top level" may be a bit of a
>> problem because it conflicts with allowing forward references.
>>
>> Ie, for example:
>>
>>     void foo() { bar(); }
>>     void bar() { i = 3; }
>>     int i;
>>
>> vs:
>>
>>     void main() {
>>         void foo() { bar(); }
>>         void bar() { i = 3; }
>>         int i;
>>     }
>>
>>
>> The first one works, but the second doesn't. And my understanding is
>> that the second one not working is a deliberate thing related to
>> not being in a declaration-only context.
>
> It's a little more than that. People have a natural view of function bodies as executing top down. Functions also tend to be simple enough that this makes sense. People have a natural view outside functions as everything happening in parallel.

Plus, this is really hard to ensure that everything is initialized properly without going eager with setting to init.
February 28, 2013
On 2/27/2013 8:01 PM, deadalnix wrote:
> Plus, this is really hard to ensure that everything is initialized properly
> without going eager with setting to init.

Yeah, the forward reference order of evaluation thingie.
February 28, 2013
On 2013-02-27 23:55, Nick Sabalausky wrote:

> I like that, but "run arbitrary code at top level" may be a bit of a
> problem because it conflicts with allowing forward references.

It would basically be an implicit "static this" declaration. I guess having to explicitly wrap it in a "static this" would be acceptable too.

-- 
/Jacob Carlborg
February 28, 2013
On 2013-02-27 22:57, Andrei Alexandrescu wrote:

> I agree we were sloppy on that. Kenji was feeling strong about and
> Walter and I didn't have particular objections, so we gave him green
> light. In the process we neglected backward compatibility.

It's at least easy to through up a new thread here to let the rest of us know, even if the decision already has been made.

-- 
/Jacob Carlborg