Matthew Sackman

This should all be fixed - please try using the latest CUE from master (or wait a week or so for the next alpha release) - I've been able to...

@freeformz from your pov, is this issue fixed now with the new trim implementation? I know you mentioned some weeks ago on slack that you'd found some new trim issues,...

@cuematthew has no clarification to offer. But @mvdan, your > any non-exported values such as definitions or hidden fields having missing required fields should not result in an error makes...

Some notes from some initial exploration of this: * pretty sure that v3 is wrong to consider this a permanent structural cycle * v2 `eval` and `export` show the same...

Huh, I barely recall filing this. That's a curious extra property then that I'd not thought about: you're suggesting that within a definition, all paths must resolve without further unification?...

@zolero There's even a non-hacky workaround! I found this issue because I was experimenting with different ways of ensuring all values within a list are "the same". The problem is...

I think this discussion runs the risk of going some way beyond the scope of this ticket. There are both slack and discord servers for CUE which are linked from...

Just as one final note on this, I'm now quite convinced this should not be an error (can you tell I've only been here a few weeks?!). Notably, this works...

So, I *think* we have this situation, following the details of https://cuelang.org/docs/reference/spec/#default-values ``` a: int | *5 b: a | *4 ``` `a` resolves to 5. The problem seems to...

> Even if something else is happening here, I think the lack of spec clarity with respect to when defaults are chosen and when references are "erased" is a problem...