> "Andrej Mitrovic" <andrej.mitrov...@gmail.com> wrote in message > news:mailman.2639.1300648308.4748.digitalmar...@puremagic.com... > > > I've just reported two issues with std.path.join: > > http://d.puremagic.com/issues/show_bug.cgi?id=5758 > > Ugh, phobos has a real problem with ctfe. There's a lot that doesn't work > as ctfe, but should. But worse than that, regressions with ctfe-ability > seem to be extremely common.
Probably because CTFE is a bit of a black art with regards to what works and what doesn't. So, it's not always obvious when something will be CTFE-able or not. I expect that the only way to really solve this is to decide which functions must be CTFE-able and add unit tests which fail if they aren't. As it becomes possible to make more functions CTFE-able, they can be made CTFE- able and have the appropriate unit tests added. But as long as none of the Phobos devs are really worrying about whether functions are CTFE-able or not (and I don't get the impression that we generally I - I certainly don't think about it most of the time), they're _not_ going to notice whether the CTFE- ability of a function changes. Though honestly, enough of Phobos is in flux and CTFE is enough of a black box that I'm not sure that it's yet entirely reasonable to require that Phobos functions stay CTFE-able once they're CTFE- able. It could be that fixing a particular bug or improving the overall design of a portion of Phobos could easily result in something becoming non-CTFE- able. Regardless, in the long run (if not the short run), this issue does need to be addressed, and Phobos devs should likely be more aware of it in general. - Jonathan M Davis