[phobos] CTFE Regressions

Jonathan M Davis jmdavisProg at gmx.com
Sun Mar 20 15:53:16 PDT 2011


It has been brought to my attention that Phobos has a tendancy to be 
inconsistent between releases with regards to what is CTFE-able and what 
isn't. Making something which is not CTFE-able so that it's CTFE-able 
generally isn't a problem, because it isn't going to break code. However, 
making a function which is CTFE-able so that it's not CTFE-able _can_ break 
code. And I suspect that this is an issue that we don't think about much when 
making changes to Phobos (I certainly haven't been).

Given the current state of CTFE and Phobos' development, I'm not sure that we 
want to get particularly strict about CTFE at the moment (CTFE _can_ be a bit 
of a black box with regards to what works and doesn't and making necessary 
changes _can_ change the CTFE-ability fairly easily sometimes). Also, it's the 
sort of thing that could change as the compiler changes, so it colud be 
completely out our hands. However, I think that the question needs to be 
raised about what we want to do about this. Making CTFE-able functions not 
CTFE-able breaks code.

The only solution that I can think of is that any function that we think 
should be CTFE-able and should _stay_ CTFE-able should have a unit test 
guaranteeing that it's CTFE-able - initialize an enum with its return value or 
whatever would be necessary to force compile time evaluation. I don't think 
that we should do that we all functions which are currently CTFE-able (enough 
stuff is in flux that I doubt that that would be a good idea), but if we pick 
a subset which really should be CTFE-able and test for it, and then over time 
as it becomes clear what else should guaranteed to be CTFE-able, we add tests 
for those functions as well. Once Phobos is appropriately mature and stable, 
it could be that every function which is supposed to be CTFE-able will have a 
test for it (and if we're really picky, stuff which isn't CTFE-able could have 
a test guaranteeing that it _isn't_ CTFE-able just so that we don't 
accidentally make it CTFE-able and then having people complaining when we the 
accidentally make it not CTFE-able once again).

This is the only thing that I can think of which would really help cut back on 
code breaking because a function stops being CTFE-able. Thoughts? Good idea? 
Bad idea? Good idea, but not right now?

I expect that we'd need to start with a fairly small subset of functions in 
Phobos, but it would at least start the process of ensuring that we don't 
break people's code because something we do makes it so that something is no 
longer CTFE-able.

- Jonathan M Davis


More information about the phobos mailing list