On Fri, 15 Jul 2011 15:57:58 -0400, Nick Sabalausky wrote: > "Lars T. Kyllingstad" <[email protected]> wrote in message > news:[email protected]... >>> 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
