Disjunctions inside a closed struct

[j-maxi]

I am wondering why this doesn't work. I want to have default.parameters closed to prevent adding a new field and declare some default parameters using disjunctions.

default: {
        parameters: close({
                name:        string
                description: string
                port:        int | *8080

                {
                        name: "custom-port-\(parameters.port)"
                } | *{
                        port: 8080
                        name: "default-port"
                }

        })
}

custom: default & {parameters: port: 9999}

I got an error when I run cue eval as fllows.

$ cue eval test.cue 
custom.parameters: conflicting values 8080 and 9999:
    ./test.cue:10:10
    ./test.cue:17:9
    ./test.cue:17:38
custom.parameters.port: 2 errors in empty disjunction:
custom.parameters.port: conflicting values 8080 and 9999:
    ./test.cue:5:23
    ./test.cue:17:9
    ./test.cue:17:38

$ cue version
cue version v0.4.0 linux/amd64

[verdverm]

Possibly at play here is #1163

The first option of your disjunction is a subset of the second. CUE sees two disjunctions i think, i.e. there are four from the port with default cross product the structs, but this may be a bug? I would expect this to resolve.

You may be able to close each part of the disjunction to get the effect you want? I believe close does not work recursively like a definition does.

[j-maxi]

@verdverm Thanks for the answer.

I figured out that it works as expected when I split the declaration into two as follows.
I expect that the original would work as well, though.

default: {
        parameters: close({
                name:        string
                description: string
                port:        int | *8080
        })

        parameters: {
                name: "custom-port-\(parameters.port)"
        } | *{
                port: 8080
                name: "default-port"
        }
}

custom: default & {parameters: port: 9999}

Interestingly, without the close clause, the disjunctions worked.

default: {
        parameters: {
                name:        string
                description: string
                port:        int | *8080

                {
                        name: "custom-port-\(parameters.port)"
                } | *{
                        port: 8080
                        name: "default-port"
                }
        }

}

custom: default & {parameters: port: 9999}

For both cases, I got

$ cue eval test.cue 
default: {
    parameters: {
        name:        "default-port"
        description: string
        port:        8080
    }
}
custom: {
    parameters: {
        name:        "custom-port-9999"
        description: string
        port:        9999
    }
}

[verdverm]

probably a closedness related bug, it is one of the more complicated aspects of the evaluator

[myitcv]

This looks like a bug to me, not least because the definition "equivalent" works as expected.

Here is a slightly simpler reproducer including the working definition equivalent, ruling out a couple of aspects that might have influenced behaviour:

# definition
exec cue eval def.cue
cmp stdout stdout.golden

# close
exec cue eval close.cue
cmp stdout stdout.golden

-- close.cue --
package y

parameters: close({
	name: string
	port: int

	{
		name: "custom-port"
	} | *{
		port: 8080
		name: "default-port"
	}

})

custom: parameters & {
	port: 9999
}
-- def.cue --
package y

#parameters: {
	name: string
	port: int

	{
		name: "custom-port"
	} | *{
		port: 8080
		name: "default-port"
	}

}

custom: #parameters & {
	port: 9999
}
-- stdout.golden --
#parameters: {
    name: "default-port"
    port: 8080
}
custom: {
    name: "custom-port"
    port: 9999
}

gives:

# definition (0.024s)
# close (0.018s)
> exec cue eval close.cue
[stderr]
custom.port: conflicting values 9999 and 8080:
    ./close.cue:10:9
    ./close.cue:16:9
    ./close.cue:17:8
[exit status 1]
FAIL: /tmp/testscript466980952/repro.txt/script.txt:6: unexpected command failure

From the error message it appears that the default of the disjunction is being selected "too early" for close.cue, which is what leads to the conflict.

Quite possibly related however is the following:

exec cue eval -c

-- x.cue --
package a

x: close({
	{
		name: int
	} | {
		name: string
	}
})

y: x & {
	name: "Hello"
}

which gives:

> exec cue eval -c
[stderr]
x: unresolved disjunction {name:int} | {name:string} (type struct):
    ./x.cue:3:4
y: unresolved disjunction {name:int} | {name:string} (type struct):
    ./x.cue:3:4
[exit status 1]
FAIL: /tmp/testscript781051936/repro.txt/script.txt:1: unexpected command failure

The error for x is expected, but the error for y is not. This suggests that with close() the evaluator tries to eliminate elements from the disjunction "too early", i.e. prior to the unification with the concrete struct {name: "Hello"}. Again, using a definition instead of close() makes the problem disappear.

@j-maxi I would suggest using a definition in the meantime, and I will raise an issue for this.

@verdverm

The first option of your disjunction is a subset of the second.

Which disjunctions are you referring to here? I'm not seeing that, and in any case a default selector is being used in both disjunctions (which would eliminate any ambiguity if there was some, but there isn't to my mind). Because name is the discriminator in the embedded struct disjunction.

[myitcv]

Raised as #1206