Proposal for std.path replacement

[Jonathan M Davis]

> "Andrej Mitrovic" <andrej.mitrovich at gmail.com> wrote in message
> news:mailman.2639.1300648308.4748.digitalmars-d at 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