Since it does break backwards compatability
Please provide example code, as the only place I know where it'd be ambiguous, it's resolved in favour of the existing behaviour, sacrificing no real functionality in the new feature.
A smart match operator doesn't seem to fill a great demand (and no, "smart match operator" is not the same as "switch", for which there are alternatives - a "smart match operator" is yet another alternative to "switch").
Smart match is what gives a switch statement for free. Of course, those can be implemented without having the smart match at all, but it'd be nice to be able to use the logic used for switch statements outside givens too.
They will demand showing you it fills a demand. So they'll suggest you first implement it in a module (a source filter probably).
The smart match operator is not in great demand. The only reason for concentrating on that is its relation with given/when. And re doing it as a source filter: no, I won't. That's very nice for a proof that the syntax works, or if you want very badly to use this feature yourself. The only thing I'm interested in is getting given/when implemented in Perl 5 itself, not a source filter, because that source filter already exists and we all know why we're avoiding its use in production. This feature requires modifications to the core (which a minor release can do -- for conservatives, there are maintenance releases), and if we're at it, I think it makes sense to do it right the first time. If p5p doesn't like it, then the work we've done has still not been done for nothing. The code that implements SmartMatch::sm can be reused without modification, and some people (like me) learn a bit about how Perl's internals work by looking at xmath's work.
But for someone who said he was doing this to avoid discussion, I have been wasting too much time on unnecessary typing already. For now, I don't care about p5p's opinion on this at all, but there will be a time that I should care, and I trust that p5p will make a wise decision.
| [reply] |
sub foo { ... }
foo ~~ $var
is now currently parsed as:
foo(~(~$_))
but from what I understand of the smart match operator, it ought to compare foo() and $var. | [reply]
[d/l]
[select] |
If you had bothered to read the original meditation, you'd have seen the remark:
Note that prefix '~~' still works like it did previously. Therefore if foo is a sub, then foo~~bar will be parsed as foo(~~bar) unless foo has prototype ().
To get a smartmatch on the result of foo, you'd write foo() ~~ $var
| [reply]
[d/l] |
