Agreed. I think this is a clear bug and just indicates that when a qr// object is used as an entire expression with different flags, the local flags should override. Similarly, when it is interpolated into a larger expression it should also be subject to local rules.

hmm, are you saying that:

$myregex = qr/test/i;
if (/$myregex = yes/) {...}
[download]

should or should not be case insensitive for the /test/ part of the regex? to me the lack of options at the end of a regex means dont use them, but it makes sence to me that the precompiled regex would force the flags given to it. I dont see the bug there...

-Waswas

My thinking is that affirmatively setting a flag should override. Since there is no way to positively unset a flag I would expect this to be a case insensitive match. Similarly, if you swapped /i between the expressions I would still expect this to be case insensitive.

Added: I'm going to moderate my opinion here. I thought a bit further and on consideration, the flags /s, /m and /x are likely not safe to have a locally specified flag override. The only qr// flag that could sanely be overridden is /i and in this case I still call the current behaviour a bug.