Sam Kington wrote: > this => $this, # might be undef or blank $this can be undef, but it can't be an empty list, or in general anything other than one list element. So "$this // undef" which you expand this to is redundant. > that => get_that_maybe() A sub call can yield any number of list elements, so this is the one that needs attention (which in this example you didn't give it). You've talked about a sub call yielding an empty list, but you omitted to mention the possibility of it yielding more than one value. The effect you're looking for for your `mandatory' fat comma is simply to put its rhs into scalar context, which is what "scalar()" or "// undef" does. >my %thing_params = (thing => $thing); >$thing_params{this} = $this if $this; >if (my $that = get_that_maybe()) { > $thing_params{that} = $that; >} >do_thing(%thing_params); can be written inline as do_thing( thing => $thing, ($this ? (this => $this) : ()), do { my $that = get_that_maybe(); $that ? (that => $that) : () }, ); >And that's annoyingly messy. It would be a lot nicer if there was >an infix operator that acted like the fat comma, but gobbled the lhs if >the rhs was undef or missing: Ah, but what should that condition be, exactly? Is it only undef that means the key should be omitted? That's not the condition you used in the above example, where you tested truthiness, not definedness, of both $this and $that. That is, should "0" be a null value alongside undef? It acts as a null in your example above, but not in the criterion you just stated. And there's the rub: the condition controlling whether the key should be included varies between situations. No single "=>?" operator can handle even the most common variations. Whereas the existing ?: operator can handle any condition. -zeframThread Previous | Thread Next