Allow optional fields for concrete types

[steeling]

Is your feature request related to a problem? Please describe.
Readability/usability. Take the following example of mapping from a source input to a target output:

#SourceSchema: {
  name: string
  address?: string
  city?: string
  state?: string
  zip?: string
  location_notes?: string
}

#TargetSchema: {
  name: string
  location: {
     address?: string
     city?: string
     state?: string
     zip?: string
     location_notes?: string
  }
}

my_source: #SourceSchema & {
  name: "steeling"
  city: "Gotham"
}

mapping_func: {
  input: #SourceSchema
  ret: #TargetSchema & {
    name: input.name
    location: {
       address: input.address | null // error: defined as a concrete here (although not in the schema), and input.address is null

       city?: input.address // doesn't evaluate/export since it is an optional field, even though it is a concrete type.

      if input.state != null { // error, can't access fields in an if statement!
        state: input.state
      }

       _zip: input.zip
      if _zip != null { // cycle error since _zip is not a concrete type...
        zip: _zip
      }

      // what you actually have to do:
     _location_notes?: *input.location_notes | null
     if _location_notes != null {
       location_notes: _location_notes
     }
      
    }
    
  }

my_target: 

Describe the solution you'd like
I'd like optional, concrete values to be evaluated/exported.
I'd also like to be able to leverage field accessors in conditional statements

Describe alternatives you've considered
N/A

Additional context
my_source is generated dynamically, and it is unclear what fields are set. We are manually creating the Mapping and applying to datasets that fit our source schema

[steeling]

Adding 4 lines in place of what could be one, with an if statement and indents, makes this super unreadable on larger files

[verdverm]

Related:

• Confusion about optional value in evaluating  #1215
• Proposal: required fields and related issues #822

[verdverm]

Field accessors do work in guards

foo: bar: true

if foo.bar {
  hello: "world"
}

But this fails when bar is optional with failed to encode: cannot reference optional field: bar

https://cuelang.org/play/?id=Smvzvo90x8Q#cue@export@json

It does seem restrictive to be unable to reference optional fields, especially when they are concrete. While it may be expected behavior today, is it desirable behavior? I'd have to reread the required fields proposal and think about if this changes afterwards.

[steeling]

Ok, I see this is possible with

if input.foo != _|_ {foo: input.foo}

Any syntactic sugar to one-liner this would be greatly appreciated!

Even foo: input.foo if input.foo != _|_ would be an improvement. We have some mappings with 100's of mapping in a single object, which can be hard to grok with the above syntax. A one-liner that keeps the LHS on the left hand side would be great.

[mpvl]

It would be interesting to hear your opinion on whether #822 would address you issue.

[rogpeppe]

@mpvl #822 is a large issue! Perhaps you could elaborate on exactly how it might help in this scenario?

[rogpeppe]

@steeling

Ok, I see this is possible with

if input.foo != _|_ {foo: input.foo}

Any syntactic sugar to one-liner this would be greatly appreciated!

I agree. This is a very common pattern when deriving one struct from another, both of which have optional fields and it would be nice for it to be more syntactically lightweight.

[sdboyer]

Strong need for this in thema, as well - having to do this is a significant source of complexity for lens authors