[phobos] Split std.datetime in two?

[Robert Jacques]

On Fri, 11 Feb 2011 14:20:09 -0500, Steve Schveighoffer  
<schveiguy at yahoo.com> wrote:
> It looks as though Jonathan is willing to roll up the code into loops,  
> so having this debate is academic at this point, but I wanted to respond  
> to some points.
>
>
> ----- Original Message -----
>> From:Andrei Alexandrescu <andrei at erdani.com>
>>
>> On Feb 11, 2011, at 2:39 PM, Steve Schveighoffer <schveiguy at yahoo.com>
>> wrote:
>
>> > Please please, let's *NOT* make this a standard practice.  If a test
>> fails, I don't want to get a debugger out or start printf debugging *to  
>> find
>> the unit test*.  I want it to tell me where it failed, and focus on  
>> fixing the
>> problem.
>>
>> You find the unittest alright. With coming improvements to assert you  
>> will often
>> see the arguments that caused the trouble.
>
> This will help immensely.  Right now, you get a line number.  The rule  
> should be, if a unit test fails, it should give you enough information  
> to 1) find the failing assert and 2) give you all the information to  
> understand why the assert failed.
>
>> I don't understand how we both derive vastly different conclusions from  
>> the
>> same extensive eperience with unittests. To me a difficult unittest to  
>> find is a
>> crashing one; never ever once in my life I had problems figuring out  
>> why an
>> assert fails in a uniitrst, and worse, I am incapable to imagine such.
>
> foreach(x; someLongArray)
>   assert(foo(x) > 5);
>
> which x caused the problem?  all I get is the line number for the assert.

*sigh*

  foreach(x; someLongArray)
    assert(foo(x) > 5, text(x) );

Problem solved. Personally, I don't usually add the extra clause to assert  
during initial coding; only when they fail do I add something like  
text("\nx:\t",x,"\nfoo:\t",foo(x)); or whatever. (Though enforces are a  
different story)