Skip to content
This repository has been archived by the owner on Nov 18, 2021. It is now read-only.

cmd/cue: incomplete value from default #577

Closed
myitcv opened this issue Oct 28, 2020 · 4 comments
Closed

cmd/cue: incomplete value from default #577

myitcv opened this issue Oct 28, 2020 · 4 comments

Comments

@myitcv
Copy link
Contributor

myitcv commented Oct 28, 2020

What version of CUE are you using (cue version)?

$ cue version
cue version +409dacf linux/amd64

Does this issue reproduce with the latest release?

Yes

What did you do?

package x

#Guide: {
	x: Steps.scenario_a.step1
	y: *Steps.scenario_a.step1 | #Step

	Steps: scenario_a: step1: *Steps.step1 | #Step

	Steps: step1: #Step
}

#Step: {
	Age: int
}

g: #Guide & {
	Steps: step1: #Step & {
		Age: 5
	}
	Steps: scenario_a: step1: #Step & {
		Age: 4
	}
}

Then:

$ cue eval --out json

What did you expect to see?

{
    "g": {
        "x": {
            "Age": 4
        },
        "y": {
            "Age": 4
        },
        "Steps": {
            "scenario_a": {
                "step1": {
                    "Age": 4
                }
            },
            "step1": {
                "Age": 5
            }
        }
    }
}

What did you see instead?

g.y: incomplete value {Age:4} | {Age:int}

Removing the Steps field (i.e. shifting everything "up" one level) does not cause the problem to manifest.

Marking as a "new evaluator" issue for now.

@mpvl
Copy link
Contributor

mpvl commented Oct 29, 2020

This is correct behavior:

  1. a reference does not itself resolve a disjunction (a reference may be a reference to a type, after all)
  2. also from the M2 and D1 disjunction rules in the spec, you can see that both remaining values are tagged as default, so the remaining value is indeed ambiguous.

This is ultimately the result that there can be only one level of default. There may be useful to have a builtin that can at least pick a default during evaluation. Or maybe defaults should actually resolve upon reference. The idea of not doing so was that one can refer to a type that has a default as well. But maybe this is more confusing than not in practice and it seems bad practice anyway.

@myitcv
Copy link
Contributor Author

myitcv commented Oct 30, 2020

Or maybe defaults should actually resolve upon reference.

Would this then mean that there can be multiple levels of defaults?

@mpvl
Copy link
Contributor

mpvl commented Nov 18, 2020

Would this then mean that there can be multiple levels of defaults?

No that would still not mean that. It would even mean there is less possibility to propagate defaults than there is now.

@cueckoo
Copy link

cueckoo commented Jul 3, 2021

This issue has been migrated to cue-lang/cue#577.

For more details about CUE's migration to a new home, please see cue-lang/cue#1078.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants