On Friday, 26 June 2015 at 13:14:40 UTC, Adam D. Ruppe wrote:
> Nothing jumps out at me as being especially bad. The posix escape codes could also be Windows compatible by rewriting them somehow, instead of building a string, make a struct message { int color; string text; } or something that you pass to the thread... but since that's an internal implementation detail that isn't necessary to work, meh.

Yeah, I know. If I'm not mistaken you have a library for that but I didn't want to introduce a dependency. Doing colour output on Windows is just annoying so I left it.

If Phobos had something like that already though...

> The docs in package.d could show more higher level examples too, before I looked at the code, I didn't realize there was more to it.

I'll see if I can whip some more up.

Atila

On Friday, 26 June 2015 at 13:32:39 UTC, Dicebot wrote:
> Just in case it wasn't clear : I will vote "no" on this proposal as long as it features longish "readable" names like "shouldEquals".

You'd rather `should!"=="`? I'm not sure which I'd prefer; the thing is that so far you're the only one strongly against it. The only other thing I heard was a question at DConf on why it wasn't `assertEquals` instead.

Atila

On 26-Jun-2015 17:30, Atila Neves wrote:
> On Friday, 26 June 2015 at 13:32:39 UTC, Dicebot wrote:
>> Just in case it wasn't clear : I will vote "no" on this proposal as
>> long as it features longish "readable" names like "shouldEquals".
>
> You'd rather `should!"=="`? I'm not sure which I'd prefer; the thing is
> that so far you're the only one strongly against it. The only other
> thing I heard was a question at DConf on why it wasn't `assertEquals`
> instead.
>

FWIW I totally prefer should!"==" to shouldEquals.

-- 
Dmitry Olshansky

On 6/26/15 7:30 AM, Atila Neves wrote:
> On Friday, 26 June 2015 at 13:32:39 UTC, Dicebot wrote:
>> Just in case it wasn't clear : I will vote "no" on this proposal as
>> long as it features longish "readable" names like "shouldEquals".
>
> You'd rather `should!"=="`? I'm not sure which I'd prefer; the thing is
> that so far you're the only one strongly against it. The only other
> thing I heard was a question at DConf on why it wasn't `assertEquals`
> instead.
>
> Atila

Let's paint this bikeshed!

I tend to like "must" instead of "should"; it's a bit shorter and stronger.

I tend to like dot-separated English for testing, e.g.

throwRangeError.must.throw!RangeError;

One advantage is that the dot after "must" (or "should") can trigger code completion on IDEs.

Finally, I wonder if it's possible to hijack operator overloading to support this:

2.timesTwo.must == 4;

On 26/06/15 17:20, David Gileadi wrote:

> Let's paint this bikeshed!
>
> I tend to like "must" instead of "should"; it's a bit shorter and stronger.

I prefer "should".

> I tend to like dot-separated English for testing, e.g.
>
> throwRangeError.must.throw!RangeError;
>
> One advantage is that the dot after "must" (or "should") can trigger
> code completion on IDEs.

It will also be more composeable. Currently there are a couple of assertions that have no negative form, i.e. "shouldBeTrue". If should/shouldNot would be separate from the actual comparison it would be possible to write "shouldNot.beTrue". It could also support custom assertions in the future: "should.beA!(Foo)".

> Finally, I wonder if it's possible to hijack operator overloading to
> support this:
>
> 2.timesTwo.must == 4;

Yes and no :). For plain "==" it's possible, but not for ">=" and the other greater/less/negative comparisons. All these operators are implemented using the same method. Although there's an enhancement request (somewhere) to support overloading these operators separately.

-- 
/Jacob Carlborg

On 26/06/15 15:32, Dicebot wrote:
> Just in case it wasn't clear : I will vote "no" on this proposal as long
> as it features longish "readable" names like "shouldEquals".

You would vote "no" because of this?

-- 
/Jacob Carlborg

On Friday, 26 June 2015 at 15:32:47 UTC, Jacob Carlborg wrote:
> On 26/06/15 15:32, Dicebot wrote:
>> Just in case it wasn't clear : I will vote "no" on this proposal as long
>> as it features longish "readable" names like "shouldEquals".
>
> You would vote "no" because of this?

Totally. Remember - this is effectively will make specific API a language standard which will propagate it to all sort of 3d party libraries. I find it unacceptably unreadable and verbose, to the point it will make working with those libraries considerably harder.

I use `test!"=="(a. b)` which is:
- short
- robust (supports any binary operator D has)
- straight to the point (it is about testing, not about what program should/must do)

The fact that examples uncourage UFCS abuse makes it even worse. Something that looks like this:

`2.timesTwo.shouldEqual(4)`

.. gets immediately marked as garbage in my book.

There are also things like `shouldBeFalse` and `shouldBeTrue`. I couldn't imagine anyone seriously using names like that until I have examined that proposal.

On Friday, 26 June 2015 at 15:20:43 UTC, David Gileadi wrote:
> On 6/26/15 7:30 AM, Atila Neves wrote:
>> On Friday, 26 June 2015 at 13:32:39 UTC, Dicebot wrote:
>>> Just in case it wasn't clear : I will vote "no" on this proposal as
>>> long as it features longish "readable" names like "shouldEquals".
>>
>> You'd rather `should!"=="`? I'm not sure which I'd prefer; the thing is
>> that so far you're the only one strongly against it. The only other
>> thing I heard was a question at DConf on why it wasn't `assertEquals`
>> instead.
>>
>> Atila
>
> Let's paint this bikeshed!
>
> I tend to like "must" instead of "should"; it's a bit shorter and stronger.
>
> I tend to like dot-separated English for testing, e.g.
>
> throwRangeError.must.throw!RangeError;
>
> One advantage is that the dot after "must" (or "should") can trigger code completion on IDEs.
>
> Finally, I wonder if it's possible to hijack operator overloading to support this:
>
> 2.timesTwo.must == 4;

Yes, this works for `==`. Unfortunately it doesn't work for anything else, including but not limited to `!=`. Oh, I tried. Even though `==` is clearly going to be the most used one, I don't like the idea of having to use a compile-time string for the other ones.

Atila

On Friday, 26 June 2015 at 15:46:28 UTC, Dicebot wrote:
> On Friday, 26 June 2015 at 15:32:47 UTC, Jacob Carlborg wrote:
>> On 26/06/15 15:32, Dicebot wrote:
>>> Just in case it wasn't clear : I will vote "no" on this proposal as long
>>> as it features longish "readable" names like "shouldEquals".
>>
>> You would vote "no" because of this?
>
> Totally. Remember - this is effectively will make specific API a language standard which will propagate it to all sort of 3d party libraries. I find it unacceptably unreadable and verbose, to the point it will make working with those libraries considerably harder.
>
> I use `test!"=="(a. b)` which is:
> - short
> - robust (supports any binary operator D has)
> - straight to the point (it is about testing, not about what program should/must do)
>
> The fact that examples uncourage UFCS abuse makes it even worse. Something that looks like this:
>
> `2.timesTwo.shouldEqual(4)`
> .. gets immediately marked as garbage in my book.

Your UFCS abuse is my UFCS awesomeness. It doesn't _make_ you use UFCS though, nobody would stop you from writing `shouldEqual(timesTwo(2), 4)` instead, which I think is nearly as readable. "Nearly" because I prefer UFCS. The advantage of using a word like "should" is that it enables UFCS, which "test" doesn't. After that it's a question of code style preferences whether or not you use it.

Atila

On Saturday, 27 June 2015 at 16:44:49 UTC, Atila Neves wrote:
> Your UFCS abuse is my UFCS awesomeness. It doesn't _make_ you use UFCS though, nobody would stop you from writing `shouldEqual(timesTwo(2), 4)` instead, which I think is nearly as readable. "Nearly" because I prefer UFCS. The advantage of using a word like "should" is that it enables UFCS, which "test" doesn't. After that it's a question of code style preferences whether or not you use it.

And disagreement about how idiomatic such style preferences should be is exactly the reason why I will vote "no".

Look at it this way : if this proposal will never get to Phobos, I won't lose anything. It does not have any really important utility I need in standard library. Main thing about this proposal is making certain testing style standard - and thus there is no practical reason to accept any compromises.