Issue with hidden refs/lists/modules

[mattklein123]

I think this is a bug but I'm not completely sure. I found this issue in a much larger example and boiled it down to a much smaller case, that AFAICT seems to require the use of modules vs. putting everything in the same package and running all cue files together.

test.cue

package function

import "example.com/lib"

// Call transform
result: lib.#Transform & {_in: ["hello"]}

lib.cue

package lib

#Transform: {
	// Input for the caller
	_in: [...]
	// output for the caller
	out: [...]

	// set output
	out: _in
}

mklein@mklein-x1:~/Source/test$ cue eval test.cue 
result: {
    out: []
}

I would expect out to contain ["hello". And in fact if I switch _in_ to in it does.

I think this is a bug but I'm new to all of this so let me know. :) Thank you.

[verdverm]

Hidden values / fields do not cross package boundaries, similar to how private works in Go. That is why it works when they are in the same package, but does not when using imports (which themselves require a module setup).

Arguably, this could emit an error. #629 is related in that packages are left open after import, which is likely to change.

[verdverm]

@mattklein123, separately, CUE uses the txtar file format from Go's source to nice reproducers & examples

https://github.com/cue-lang/cue/wiki/Creating-test-or-performance-reproducers

[mattklein123]

@mattklein123, separately, CUE uses the txtar file format from Go's source to nice reproducers & examples

Got it, OK. Sorry about that.

Arguably, this could emit an error. #629 is related in that packages are left open after import, which is likely to change.

OK, I see. FWIW this is not very intuitive, given that hidden variables are a way to hide input from the output. An error would be very nice here, thank you.

[mattklein123]

I've been thinking about this more, and it seems like not being able to pass hidden "inputs" into a module makes modules much less powerful than they could be. Obviously, the caller could be aware of the "in" and "out" pattern, but then the caller has to do the filtering for fields that shouldn't be in the final output which breaks the abstraction. Any thoughts on this? Any other pattern I should be using?

[verdverm]

You can use #in for input, which will not be output and also puts a schema on the input value.

There is also the "function" pattern and proposed syntactic sugar (#943)

[mattklein123]

You can use #in for input, which will not be output and also puts a schema on the input value.

I want to make sure I'm not missing something obvious, but I don't see any way to hide the input value from the ouput.

-- cue.mod/module.cue --
module: "example.com"
-- lib/lib.cue --
package lib

#in: string

#Transform: {
        in: #in
        out: in
}
-- test.cue --
import "example.com/lib"

lib.#Transform & { in: "hello" }

mklein@mklein-x1:~/Source/test$ cue export test.cue 
{
    "in": "hello",
    "out": "hello"
}

Obviously in this case "in" is part of the output. I understand that I can assign out to something at the callsite, I'm just trying to confirm that there is no other way to hide this from the caller. In general some sugar around this would be really nice.

[seh]

I'd write the input field as a definition instead, per this example.

[mattklein123]

Ah, thank you @seh. I think this is the piece I was conceptually missing. I didn't realize definitions could be nested in this way. Very cool!

[rogpeppe]

@mattklein123 It seems like you no longer consider this an issue. I'll close it accordingly. Please re-open if you still think this is a bug, thanks.