Don <> changed:

           What    |Removed                     |Added
           Severity|regression                  |enhancement

--- Comment #11 from Don <> 2011-06-30 00:42:19 PDT ---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > I'm pretty sure this is a regression between DMD 2.052 and DMD 2.053. I 
> > > found
> > > this 'regression' in template constraints:
> > > 
> > > if( isPointer!T && isPointer!(pointerTarget!T) )
> > > 
> > > the problem is that if T is a string, then pointerTarget!T can not 
> > > compile.
> > > This wouldn't be an issue if that meant the template constraint failed
> > > gracefully, but instead it halts compilation.
> > 
> > No, that's not a regression. && was never defined to work in that way.
> > It's a Phobos bug which has been exposed.
> Don, this compiled prior to DMD 2.053 and was in my code, not Phobos. It _is_ 
> a
> change from existing behavior. (Whether that change is a bug fix or a
> regression is debatable)

OK, I've figured this out.
The change in behaviour was because of this commit:
which suppresses spurious _error messages.

What was happening with X && Y was that an error message was being generated
while evaluating the Y, but because error messages were suppressed, you didn't
see the error message. This is the important thing: it has ALWAYS generated an
error message.
Then, && gets constant folded. The constant folding assumes there are no
errors, but because X is false, it const folds to false without looking at Y.
(If it did look at Y, it would have crashed).
This was incorrect behaviour, but normally it didn't matter, because an error
message had been displayed already anyway.
And finally, the template constraint didn't do a sanity check to see if any
errors had occurred, it simply checked the result.

The net effect of this was that (false && _error) normally didn't compile, but
if it was inside a template constraint, it did compile!

So it was definitely an accepts-invalid bug that got fixed. Not a regression.
It wasn't supposed to do that, and there's nothing in the spec to suggest that
it should have behaved in that way.

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

Reply via email to