salortiz
commented
2 years ago If your real concern is the "worry" produced by the compiler, these can be turned off by a simple 'no worries` pragma.
{ no worries; say 'almafa' ~~ S/a/e/ } # FalseBut I don't understand your use case.
The S/// operator returns a Str, not a Regex, so when used as the RHS of the smartmatch operator ask for a string equality comparison that returns a Bool, that will be True if and only if the substitution requested becomes a NOP (i.e. nothing was substituted). Anyway the result of the substitution is lost.
Am I missing something?
2colours
lizmat
vrurg
jubilatious1
'almafa' ~~ S/a/e/(along with any smartmatch to an S/// construct) produces a "worry", even though the already existing behavior is reasonable and already has analogous precedents with other regex quoting constructs.To provide some context regarding the phenomenon:
Potential difficulties: Smartmatch with S/// is not useful. You can use given instead: S/// given $fooHere I am going to argue that the behavior should not be considered "worrying", without any modification otherwise.
when S/a/e/ {}is indeed useless. However, we do use smartmatching with completely different motives than given/when structures. The documentation is a good example: it's full of code that uses smartmatching to regexes in order to obtain the match object, for example:say "Zen Buddhists like Raku too" ~~ $regex; # OUTPUT: «｢Raku｣». If smartmatching exists (and is commonly used) outside of boolean context, why not acknowledge that smartmatching per se isn't a problem with S///?$a ~~ S/x/y/and$a ~~ m/x/aren't only visually similar; their behavior is strongly analogous:~~is an operator that you can use as many times in an expression as you wish,givenis a statement modifier that you can only use once in a statement. They are on different conceptual levels. The situation can be improved by usingandthenfor setting the topic variable, or using a.&{ S/// }call on something; however, if your intention with using smartmatch for substitution was clear, these all still seem workarounds, not proper alternatives.$foo ~~ S/a/b/ ~~ S/c/d/is a good-looking paradigm :) I admit that this might be an unusual take but I definitely consider it a pro, worth mentioning. Thanks to the topic-setting nature of smartmatching (i.e the same thing that makes substitution with smartmatching possible in the first place), this chain will (although with redundant steps) execute just right, hence making S/// itself more useful. I wouldn't be surprised if the execution could be optimized almost with the same effort as the "worry" is generated; the syntax to recognize is almost the same. Mind you: this works "for free", completely respecting the properties of smartmatching - except the unwritten, implicit, already violated expectation that it should be boolean-centric.For me, this issue was already insightful, and I think it's good to think about smartmatching for a while. I personally think that as easily as removing a "worry" and a "note" from the documentation, we could increase both consistency and fun, and that might be the easiest way out. However, there are theoretical implications (mostly about smartmatch but also about these regex "operators") that can be investigated in many different ways.