New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Let s/// return according to spec. WAS: Give the result of s/// a Bool mixin. #295
Conversation
|
I'm less than thrilled by mixing Bool into basic types in the setting. It might "do what I mean" in this particular context, but the result is normally a string that can be passed to anywhere else, and that anywhere else might be very surprised by strings not boolifying in the normal way. The problem must really be solved at the spec level first, not monkey-patched in rakudo. (IMHO the same goes for tr///, but I kept quiet there, hoping it would be just a very localized thing; but I don't want the mixing-in theme to spread). |
|
@moritz: Right, mixins in the setting aren't great. That's not (anymore) what this PR implements, though, even though I clearly forgot to mention that it isn't. Sorry about the confusion. |
|
There has been a bit more discussion here, which coupled with my own re-reading of S05 has resulted in the latest changes. |
As per the referenced spec commit, s/// is supposed to always return a Match object or Nil if there was no successful match.
Some adverbs (:g, :x, :ov, :ex) are supposed to return a Match objects that contains all submatches and has slightly different semantics in some cases.
Behavior of m:g// and s:g/// should now rather closely match S05, section "Capturing from repeated matches" and the last two paragraphs of the section "Substitution".
|
I would consider this branch "to spec", as it is now. Because this might break a few things in a few places (outside of Rakudo itself, I did take care of that, to the best of my knowledge) there should maybe be some kind of deprecation cycle before this becomes mainline. Obviously some tests broke as well, I have created a branch in perl6/roast locally, which I can push. It mostly contains fixes regarding the difference mentioned above. Edit: Here is the branch mentioned above. |
|
There's been a bit more discussion on this around here, which suggests merging of this PR should be delayed until after the list refactor pmichaud++ has taken upon himself, mainly to conserve the |
|
This PR is likely obsolete, as |
This refers to RT #82108. The performance and semantic concers
raised by jnthn++ obviously still exist.
For reference: https://rt.perl.org/Public/Bug/Display.html?id=82108