localized form if/else to deduplicate predicate

[kghenderson]

Is your feature request related to a problem? Please describe.
Not a bug, but definitely leads to errors.

I have a lot of optional/conditional fields, which leads to a lot of cue code looking like this:

SourceThing?: string // optional, so can't explicitly reference

NewThing: string
if (SourceThing == _|_ ) { NewThing: "nope", MissingThings: SourceThing: true }
if (SourceThing != _|_ ) { NewThing: SourceThing, FoundThings: SourceThing: true  }

or

SourceThing?: string // optional, so can't explicitly reference

NewThing: string
_newThingExists: boolean & { SourceThing != _|_  } // capture predicate
if _newThingExists { NewThing: "nope", MissingThings: SourceThing: true }
if !_newThingExists { NewThing: SourceThing, FoundThings: SourceThing: true  }

this is a stretched example, but there's so much repetition here and it's very manual and error prone.
also, developers take for granted good editor features like vim strokes or multiple cursors, but a lot of people (most even?), would type each character out. terseness matters (but only to the point where things remain clear and legible)

now, I also understand why cue doesn't have "else" statements because it implies time, but I think having/using eval and expansion means that we can have very localized macro type stuff. in something like lisp or ruby, macros can do anything, anywhere and it leads to very unpredictable behaviour. python is like 99% a lisp, but intentionally blocked this specific macro behaviour to increase predictability.

just saying ... i think eval expansion and cue's validation logic, means the cue situation is a little different ... maybe just goes by the name 'syntactic sugar'

it's not strictly for convenience either but for clearer intent and error reduction.
e.g. is it clear what's happening? can we directly see it's expanded output (e.g. post eval)? will it reduce errors?

we're already importing/nesting other structs and writing loops, but the expanded form is everything from everywhere brought together for you already. e.g. if the definition/struct in file A adds a derived calculated field, file/struct B implements that definition (and doesn't specify that field), then the evaluation in form C shows them together .... it's still kinda like macros but still WYSIWYG (what you see is what you get) and not hidden/unexpected, imho the best of both worlds. this is an amazing and desired feature of cue.

also, this is only for if/else (like go) and not for if/elif/elif/else ... those aren't reversible and that's an extremely important quality, but for a pure boolean predicate, true and not true are reversible (once expanded). this objective and logical reversibility is what sets this specific request apart.

Describe the solution you'd like

I'm not sure precisely what this form would look like, and is open for debate, but a very localized else, that is the inverse of the initial predicate.
e.g. (naming needs work, just an example)

if? (somePredicate) {{ OptionA } else { OptionB } }

and would automatically expand to:

if ( somePredicate) { OptionA }
if !( somePredicate) { OptionB }

which as an expanded statement, also works in this reversed fashion too:

if !( somePredicate) { OptionB }
if ( somePredicate) { OptionA }

Describe alternatives you've considered
Just writing out the long forms, explained above.

Additional context
I have lots of thoughts/opinion on changes/advancements to function processing in cue (someday),
but here's the thing: a "good" developer might separate the predicate into a boolean an inverse it,
so as to not have to repeat the logic and keep it DRY (don't repeat yourself). But many users (sadly even myself at times being lazy or not thinking), will just copy their whole predicate statement,
and then try to keep them in sync manually (and poorly).

if ( ThingA && Thing B || Thing C && !ThingD ) { OptionA } 
if ( !ThingA || Thing B && Thing C || ThingD ) { OptionB }
// i did this incorrectly, but it's an example of what we'll see when people try to reverse/inverse things themselves
// the predicate & !predicate is way safer, but doesn't come naturally to non-developers

[myitcv]

Thanks for raising this @kghenderson. I've created #2122 to pull together feedback from various places, including your own issue (I didn't want to take over your issue, rewriting the description). Your issue (this issue) is linked from there as one (important) piece of feedback.

So I suggest we close this and continue conversation there.