I suspect it may be some weirdness with the way that $_ is being handled in smartmatching, then.
I think there's a slight difference between $tmpl ~~ /regex/ and $tmpl ~~ m/regex/ The first one does the equivalent of /regex/.ACCEPTS($tmpl), which ends up matching $tmpl directly against the regex and returning the resulting Match object. The second one temporarily assigns $tmpl into $_, then m/regex/ does an immediate match against underscore to produce a Match object, which then has .ACCEPTS($tmpl) called on it (which returns the Match object). I don't know exactly what is happening when !~~ is used with m/.../ -- i.e., when $_ is being assigned, what is happening to the Match object, and where negation is taking place. It would be interesting to know if the following fails for you also: if not $tmpl ~~ m/\.txt$/ { ... } Pm On Tue, Dec 30, 2014 at 09:29:39AM +0200, Gabor Szabo wrote: > No. If I remove the leading m from the regex, then the bug is gone. > Gabor > > On Tue, Dec 30, 2014 at 9:19 AM, Patrick R. Michaud <pmich...@pobox.com> > wrote: > > > Out of curiosity, is the bug still present if you use /\.txt$/ instead of > > m/\.txt$/ ? > > > > At the moment it looks like a Rakudo bug to me, but I haven't been able to > > golf it further to be certain. > > > > Pm > > > > On Tue, Dec 30, 2014 at 09:11:52AM +0200, Gabor Szabo wrote: > > > Just to follow-up: > > > The problem appears in > > > > > https://github.com/szabgab/Perl6-Maven/commit/4346c96d63e97def55e789bbeebdbdaebe8b0b33 > > > > > > After that I have replaced the regex match with > > > > > > if substr($tmpl, *-4) ne '.txt' { > > > > > > that works correctly, but I'd still like to understand if the bug was in > > my > > > code, or if this is some Rakudo issue? > > > > > > Gabor > > > > > > > >