You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This took me a while to understand why line 7 above name?: #First.name is errorneous. The confusion came from the fact that I specified a concrete value in the last: evaluated value so I thought that everything should checks out and the value export should succeed but it seemed that:
Optionals are evaluated earlier that the process of collapsing values to a final concrete exportable one.
Because #First.name is optional, referencing it in #Second does not make sense because optional-ness is not a property that is passed along 1st-class like regular string or int type specifier are.
My flawed thinking was that I thought the optional-ness of a field would be passed along just like string or int would and gets merged (union?) to produce a valid final value. Something like optional & 1 == 1 but optional & _|_ == _|_ which actually doesn't seem useful once I think about it this way.
It seems like it's not exactly a part of the type system, but more of a constraint on the struct type in general.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
playground: https://cuelang.org/play/?id=t-73DC9ZoVe#w=function&i=cue&f=export&o=cue
This took me a while to understand why line 7 above
name?: #First.nameis errorneous. The confusion came from the fact that I specified a concrete value in thelast:evaluated value so I thought that everything should checks out and the value export should succeed but it seemed that:#First.nameis optional, referencing it in#Seconddoes not make sense because optional-ness is not a property that is passed along 1st-class like regularstringorinttype specifier are.My flawed thinking was that I thought the optional-ness of a field would be passed along just like
stringorintwould and gets merged (union?) to produce a valid final value. Something likeoptional & 1 == 1butoptional & _|_ == _|_which actually doesn't seem useful once I think about it this way.It seems like it's not exactly a part of the type system, but more of a constraint on the struct type in general.
Is this the correct way to think about it?
Beta Was this translation helpful? Give feedback.
All reactions