IP types

[cueckoo]

Originally opened by @xaque208 in cuelang/cue#878

I see the following Go package that contains some bits about IP address, but I'm unsure how to make use of that from cue.

https://github.com/cuelang/cue/blob/master/pkg/net/ip.go

I'd like to ensure that a yaml document might have a value with a real IP type, for example. Advise welcome.

[cueckoo]

Original reply by @myitcv in cuelang/cue#878 (comment)

@xaque208 this is a bit subtle, not least because of #863. There is a constant goal to improve documentation and with the release yesterday of v0.3.0 we can start to take more steps towards that goal.

The subtle point here is that net.IP() can be used as a zero-argument constraint, even though it appears it requires and argument:

package x

import "net"

#machine: {
	ip: net.IP()
}

laptop: #machine & {
	ip: "4.4.4.4"
}

desktop: #machine & {
	ip: "4.4.4.x"
}

If you run the above as follows:

$ cue export
desktop.ip: invalid value "4.4.4.x" (does not satisfy net.IP):
    ./x.cue:6:6
    ./x.cue:14:6

[cueckoo]

Original reply by @xaque208 in cuelang/cue#878 (comment)

Great thank you. Some documentation around how this works would be helpful. For example, I'm thinking that this could be extended to ensure that certain hosts conform to a specific subnet or have a specific prefix. In such a case, would this be a contribution to the net package, or something I should think about doing with a private go package? I have many subnets/prefixes and knowing that a collection of hosts belongs in a subnet seems like a use case to which cue could be applied.

That said, the above get's me started, so thank you for the explanation.

[cueckoo]

Original reply by @myitcv in cuelang/cue#878 (comment)

For example, I'm thinking that this could be extended to ensure that certain hosts conform to a specific subnet or have a specific prefix. In such a case, would this be a contribution to the net package, or something I should think about doing with a private go package?

net.IP is referred to as a builtin. Custom builtins are a somewhat tricky area because if we supported them we would immediately fracture the CUE ecosystem. So the plan is to expand the standard builtins to give the primitives required to build any constraint, with reuse either coming directly from a standard builtin, or by importing a CUE package that implements the constraints you require (we're working on a proposal for dependency management in CUE).

See also cuelang/cue#484 (comment) for ideas on how constraints can be treated as functions (and plans we have for syntactic sugar in this space)