Next in Review Queue: The New std.path

[Lars T. Kyllingstad]

On Fri, 15 Jul 2011 15:57:58 -0400, Nick Sabalausky wrote:

> "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...)

I didn't notice your CTFE-ability thread until now, because I was away on 
vacation when you posted it.  I'll make sure to read it, maybe it will 
convince me. ;)

-Lars