Next in Review Queue: The New std.path

[Nick Sabalausky]

"Lars T. Kyllingstad" <public at kyllingen.NOSPAMnet> wrote in message 
news:ivpk4e$gf5$1 at digitalmars.com...
>> 4.  This module might be useful at compile time.  As pointed out on this
>> forum, Phobos should eventually include tests for CTFE-ability.  It
>> would be nice if std.path had a few CTFE unit tests sprinkled in.
>
> I'm not sure I agree with this.  As I understand it, most of D should
> eventually be usable in CTFE.  (Don has made enormous progress in this
> regard.)  In most cases we therefore shouldn't have to change Phobos to
> make it CTFEable, it should Just Work.  On that note, it shouldn't be
> necessary to add CTFE-specific unittests either.
>

I totally understand that reasoning, but as I pointed out in the OP of the 
big CTFE-ability thread: We're currently in a situation where basic 
commonly-needed-in-CTFE functions are frequently breaking at compile-time, 
which forces D users to avoid using Phobos at compile time and reimplement 
any needed Phobos functions themselves. It would be better to just 1. Have 
unittests to detect breakages of at least the functions that are likely to 
be needed at compile-time, and 2. Insert quick-n-dirty CTFE-able alternate 
codepaths (via "if(_ctfe)") around any part of the affected functions that's 
broken at compile time.

Plus, the unittests can then stay in to help detect CTFE regressions. In 
fact, one of the CTFE bugs I reported one time was a result of a 
CTFE-ability unittest I had for one of my functions. (Although, it was a 
function that was specifically written to be used at compile time...So it 
was really just a unittest to make sure it worked as intended...)