Should without allow chaining?

[treyharris]

Currently, the rationale for why unless does not allow chaining is basically, "unless is exactly equivalent to if not, and unless...elseunless...else is confusing, so just reverse your logic if you need more than one alternative."

The same logic seems to apply to without, which, unlike with but like unless, can't have chained conditionals or an else. But does the same logic actually apply?

I've recently been writing top-level executables where I really have wished there was without...orwithout...else, because a lot of logic there is checking if conditions for execution exist (often including checking for the presence of user flags) where without is much clearer than if not defined (not to mention the subtle differences in Perl 6's vs. Perl 5's defined are a bit of a trap here).

I don't want to contribute to language bloat, but I think that cognitive load is decreased with the introduction of an orwithout and allowing chaining to without, and the prohibition against chaining after unless was always normative anyway—something I think we usually do in Perl with great hesitancy, and certainly not to promote hobgoblin-minded consistency.

Addendum: I didn't mention orelse, but that's because without EXPR1 orelse EXPR2 orelse EXPR3—while admittedly useful—isn't a substitute any more than if EXPR1 or EXPR2 or EXPR3 is a substitute for elsif.

[treyharris]

A couple of points raised on IRC:

without has a relationship to with superficially similar to that unless has to without (obviously and foremost, that given the two in a row with the same conditional expression, just one of the two will continue to execution¹), but it does not have a relationship to with that’s really analogous. To wit:

1. Any unless can be rewritten as if not, making switching to the chaining variant rather easy. But without cannot be rewritten as with, so the rationale disallowing chaining for without can’t be the same as unless. It simply doesn’t present the refactoring issue present with if vs. unless.
2. The argument of not wanting to promote the head-scratching complexity of double negation doesn’t apply, either:
   • True has an opposite of False, and False of True. not not BOOL-EXPR always equals BOOL-EXPR.
   • But a defined value’s opposite is Null, Empty, or the value’s type, depending on context. And “undefined’s opposite” is almost any value at all. There is no X such that X DEFINEDNESS-EXPR is always unequal to DEFINEDNESS-EXPR but X X DEFINEDNESS-EXPR always equals DEFINEDNESS-EXPR.
     In short, “double undefinition” is Not A Thing.

The introduction of without might or might not have been the original error, but so long as it exists, the arbitrariness that increases language complexity (from a cognitive rather than language standpoint) is that it does not have a followup like with. without is simply not like unless except in a glib missing-the-point sense.

So my argument is that either removing without entirely and making if not defined become, once again, the One Way to Do It, or adding an orwithout (or butwithout or even norwithout) and else to without—either would increase parsimony. The current status quo is maximally arbitrary.

I can find no argument for without existing yet not having a chained variant except hobgoblin “consistency” with unless.

---

¹ Assuming instantaneous execution and that the subordinate block has no side effects, anyway.

[treyharris]

One last thought for now: maximally parsimonious would be to introduce orwithout and make any combination of [with|orwith][...[orwith|orwithout]...][...else] valid.

(I’d say letting with|without mix with if would be even more parsimonious, but it makes unless‘s refusal to participate a bit uncomfortable. I could go either way on that one. But if...orwith and if...orwithout and without...elsif are all useful and cannot be generally refactored with one additional word like unless is.)