It's uncommon to use expressions that evaluate to branches passed to conditionals. And when you do use one, you probably don't mind putting it in a GROUP! (especially considering that 99% of the time in the far more common cases you were willing to put it in a BLOCK!).
So Ren-C now uses that fact--plus generalized quoting--to allow for a briefer and faster way to evaluate to literals in your conditionals:
>> if okay '[block as data]
== [block as data]
Simply pass in a QUOTED! item of any kind, and that item will be what a branch evaluates to. It will be one less level of quoting than what you pass in:
>> if okay '<tag>
== <tag>
Previous attempts to get something like this used an /ONLY refinement. But this lets you mix and match in the same operator, as opposed to switching the operator into a "mode":
>> either okay '[1 + 2] [1 + 2]
== [1 + 2]
>> either null '[1 + 2] [1 + 2]
== 3
It Solves Some Problems for CASE
Historically, CASE was more lax in accepting types than the corresponding IFs would be:
>> case [1 = 1 <foo>]
== <foo>
It would allow the by-products of arbitrary evaluation to be used:
>> word: <foo>
>> case [1 = 1 word]
== <foo>
Sometimes this resulted in double-evaluation:
>> word: [print "surprise"]
>> case [1 = 1 word]
surprise
== true
The dodgy nature of this "may be a double evaluation, may be not" with no way to tell at source level raised some concerns, which are laid out in the "backpedaling on non-block branches" post.
The combination of soft quoting and generalized quoting lets the same patterns that work for IF work in CASE. It lowers the risks in a legible way:
>> case [1 = 1 '<foo>]
== <foo>
It's Faster and More Efficient
Quoting is done with a byte in cells. So you can count up to 254 levels of quoting without really costing anything. (If you're wondering why not 255 levels since a byte can be from 0..255, it's because 255 is reserved for "isotopes".)
So '[x] costs less storage (and has better locality with the surrounding cells) than [[x]].
Outside of the reduced storage, it's also lighter on the evaluator, because it doesn't have to push an evaluator frame to run the block!
The consequences
There were very few pieces of code in the Ren-C repo that were affected. One was a help test. It wanted to generate a real-world block to run, and didn't want to call DO for some reason:
for-each w words of lib [
dump w
if not set? w [continue]
if action? get w
compose [help (w)] ; errors now...IF thinks the COMPOSE word! is branch
else [
help (get w)
]
]
It's easy enough to change that to (compose [help (w)])...this kind of usage is very rare.
The one common case of passing code to a conditional originated from Ren-C...the use of lambdas that could take the argument of what drove the conditional:
trap [1 / 0] then error -> [print [error]]
So you have to put it in a GROUP!:
trap [1 / 0] then (error -> [print [error]])
I'm pretty sure this can be rethought to work as before, given the strategy of "right quoting always wins". But the evaluator has some kind of strict horse-blinder rules that guide its design, so not all things are possible. We'll see.
UPDATE 2020: The required rules have been implemented, and hard quoted left parameters on the right win in this instance, so the group is not necessary.
Even if it couldn't get fixed, in the scheme of things it's worth it. And it isn't like people aren't used to putting branches in delimiters for blocks anyway!
But looks like soft literal branches are safe.