-
Notifications
You must be signed in to change notification settings - Fork 302
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cue/format: most options are not respected #2404
Comments
The docs almost certainly need improving here, hence the |
@myitcv this was working before 0.5.0, so this is something that broke existing code we've had for many versions. I think (added output from 0.4.3 to original description) edit, I may have my testing matrix output confused... will update what is curious is that
|
Upon further investigation, the behavior looks to be stable. What does make a difference is if you use a I generally think the documentation makes sense as is for what the expected behavior ought to be, and that the implementation probably needs more conditions to cover the non-final path. There are some other curiosities, like setting hidden implies the definition setting is the same (https://github.com/cue-lang/cue/blob/v0.5.0/cue/types.go#L2181) |
Another important aspect is that the order of options applied also matters, and later options can override earlier options. Underneath, these Option functions set values in a struct. I think a better API would expose the options as a struct, so the user can set them as appropriate and avoid the opaque ordering issue in the current API. It would be much more declarative than imperative, i.e. order shouldn't matter, like CUE :] final first
final last
|
What version of CUE are you using (
cue version
)?Does this issue reproduce with the latest stable release?
No, but it worked as expected in 0.4.3
What did you do?
What did you expect to see?
What did you see instead?\
Output from
v0.4.3
The text was updated successfully, but these errors were encountered: