Request
Add a recipe for tolerant field projection — selecting/cutting only the fields that are actually present on a record.
super_recipes currently has nothing for this (searches for cut and has both return zero results), yet it's a frequent need precisely because super 0.3.0 is strict: a bare cut field (or any reference to field) hard-errors at compile time when the input's inferred type uniformly lacks field, and ??/coalesce/cut field? can't rescue an absent reference. See the companion issue on documenting that strictness.
So users with heterogeneous/optional-field data have no clean idiom to say "project these columns, tolerating absence." Today the workaround is to filter to a homogeneous subset first, then cut — which is awkward to express generically.
Possible shapes
sk_cut_present — an operator that projects a requested field list, dropping (or defaulting) the ones a given record doesn't have, without compile errors.- a safe record-builder that fills absent fields with a default (
""/null), using has() under the hood (has() appears tolerant of absent fields where bare references are not).
Either would be more broadly useful than several of the existing string helpers, given how often this comes up when reshaping real-world JSON.
Context
Hit this migrating a real script off zq: needed to display a fixed column set over records that don't all carry every column. zq's cut tolerated missing fields; super 0.3.0 doesn't, and there's no recipe to bridge the gap.
Request
Add a recipe for tolerant field projection — selecting/cutting only the fields that are actually present on a record.
super_recipescurrently has nothing for this (searches forcutandhasboth return zero results), yet it's a frequent need precisely because super 0.3.0 is strict: a barecut field(or any reference tofield) hard-errors at compile time when the input's inferred type uniformly lacksfield, and??/coalesce/cut field?can't rescue an absent reference. See the companion issue on documenting that strictness.So users with heterogeneous/optional-field data have no clean idiom to say "project these columns, tolerating absence." Today the workaround is to filter to a homogeneous subset first, then cut — which is awkward to express generically.
Possible shapes
sk_cut_present— an operator that projects a requested field list, dropping (or defaulting) the ones a given record doesn't have, without compile errors.""/null), usinghas()under the hood (has()appears tolerant of absent fields where bare references are not).Either would be more broadly useful than several of the existing string helpers, given how often this comes up when reshaping real-world JSON.
Context
Hit this migrating a real script off zq: needed to display a fixed column set over records that don't all carry every column. zq's
cuttolerated missing fields; super 0.3.0 doesn't, and there's no recipe to bridge the gap.