aha thats what ct_trace is for...
kirai84 wrote: Default value and not-set value are different things
I agree. They should be kept distinct
We should keep it to returning nil or the deref evaluation result
Its easy (and clear) enough to use nil coalesce to provide defaults if thats desired
amount = customer?.balanceDue ? 0.0
charles wrote:use a different operator
I like using
? somewhere - clearly relating to nilable and nil-coalesce
What about reversing
?. to
.?Its not quite as analogous to
?. = nil-on-prior-id-or-deref but gets the point across and is unambiguous against nil coalesce as operator
amount = customer.?balanceDue ? 0.0 # nilSafe on customer
#OK
amount = customerBal?.balanceDue # nil coalesce on customerBal to .balanceDue
# which is amount = customerBal ? .balanceDue
#Below is syntax error: 'customer.' expecting an expression
amount = customer. ? balanceDue
nerdzero wrote:Would the ?. operator short circuit or would it evaluate the entire call chain regardless?
Short cct - if any member/call prior to nilsafe-op (
?.) is nil, remainder is not evaluated in any way
I dont see the point of doing anything else.
kirai84 wrote:should turn into this..
(a == null ? null : (a.rest))
(a == null ? (V?)null : (a.rest))
if (a != null), a.rest
# These are same as non nil coalesce:
a ! a.rest
My current (faster) implementation does a rewrite using non-nil coalesce.
I think we probably need to see what the effect is of forcing spaces around (some) ops before chasing other op combos