Don <> changed:

           What    |Removed                     |Added
                 CC|                            |

--- Comment #7 from Don <> 2011-06-06 01:45:43 PDT ---
(In reply to comment #4)
> Unless I'm missing something, actually intermixing evaluation and semantic
> analysis enough to pull this sort of thing off would be enormously intrusive.
> Additionally, do we _really_ want compile time code execution semantics to be
> that different from runtime execution semantics?  My gut says, "No way."

There are *no* existing instances where CTFE ever does semantic analysis.
CTFE happens far too late for that. In fact CTFE isn't involved at all, the
desired behaviour would happen in the constant folding step -- but it doesn't
do semantic analysis either.
This would seem to be a request to change the semantics of the && operator to
allow things like:

enum bool XXX = false && undefined;
to compile. As well as being complicated to implement, I really don't think
that would be a good idea. It would introduce a corner case:

bool YYY = false && undefined;  // doesn't compile, still won't compile?
const bool ZZZ = false && undefined; // I think this must be forbidden.

is(typeof(false && undefined)) presumably would still return false, even though
it does compile in the XXX case.

Would any of these compile?

bool foo(bool z) { return z; }
enum bool AAA = foo(false && undefined);
enum int BBB = (false && undefined) ? 7 : 3;
enum int CCC = false ? undefined : 6;
enum bool DDD = true || undefined;
enum bool BBB = !((true || undefined)) && undefined2;

The thing which is particularly difficult about implementing this, is that you
cannot run the semantic pass on the second branch of an && expression, until
you have run the optimizer pass on the first branch.

And what happens with this:
enum bool CCC = is(typeof(false && undefined));
Currently that returns false.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to