Feature: Weighted default / Idiomatic way of changing the default

[ghostsquad]

Is your feature request related to a problem? Please describe.

I'm building an opinion-based layer system, and I'd like to use things like "foo" | *"bar" (think about how the "if null then X" is the behavior of many fields), but allowing someone else to come along and say, actually, I prefer that foo be the default instead if the user doesn't specify something different.

Describe the solution you'd like

Either an explanation of how to accomplish this, or syntax to allow for a weight-based preference to default values.

Describe alternatives you've considered

N/A - I'm still learning CUE, coming from Jsonnet experience. Trying to figure out how to accomplish this common use-case.

Additional context

N/A

[kghenderson]

note that, depending on your use case and if/how users interact, you could also do things a bit the old fashioned way: like how you might do it excel or python or another language ... e.g. have a ValueUserInput, ValueUserDefault, ValueSystemDefault, and ValueFinal ... UserInput is what they've entered, SystemDefault is the provided default, UserDefault is the custom one, and Final is a formula which checks for those values (with != _|_ aka "not equal to bottom"), checking them in sequence. the naming is up to you, and you can do this as a series of if statements or perhaps add them to a list and coalesce (comprehension where not bottom) - just thought of this list option though so it might need some more thought - just trying to save what could be a complex set of nested if statements. if this seems like something you'd like to try, let me know and i'll test it out.

[ghostsquad]

The problem is that what you are describing is a LOT of boilerplate that I would have to apply to literally every value.
Another downside to this proposal is that I must predefine how many layers there are. My goal is to make the number of layers arbitrary.

[ghostsquad]

So an example, from the tutorials is this:

*"tcp" | "udp"

this says, it can only be udp or tcp , and without further input, it will resolve to tcp.
and with:

*"tcp" | "udp"
"tcp" | *"udp"

it's ambiguous, and is essentially the same as if I didn't have a preferred mark at all

so, what if I could mark *"udp" as weighted heavier than *"tcp"
essentially meaning, without further input, this will be udp because it's weighted heavier

I suppose this would be most similar to a max function, but not caring about the value, just the preference for such a value.

Technically CUE already supports this, since a concrete value has "infinite" weight, and the preferred mark is somewhere between concrete and arbitrary (within the defined bounds).

And there are other similar functions, such as null/bottom coalescing.

[ghostsquad]

Here's an idea:

*"tcp" could be equivalent to prefer("tcp", 0), where the second parameter to prefer is the weight of the preference.

This system could work similar to priorityclass in Kubernetes. The default priority is 0, and any valid int32 value, positive or negative is allowed. Pods are scheduled based on their priority.

[ghostsquad]

turning the preference mark into a function has additional benefits in that you could declare the preference as part of an expression, such as in a comprehension.

[zzh8829]

Hello I am also very invested in this idea. here is my proposed solution

adding the concept of weighted priority on defaults with
*(weight)value

val = *(0)val  
*val = *(1)val

combining two values in disjunction
*(x)val & *(y)val = *(max(x,y))val

what do you gues think about this

here is an example of it in practice

[zzh8829]

more generically speaking, a field has no default when the max(weight) contains multiple valid values.

[myitcv]

@ghostsquad thanks for raising this, and welcome to CUE!

Does the following approach satisfy your requirements?

#A: {
    defaults: {
        k8s?: string
        user?: string
        more?: string
        evenMore?: string
    }
    
    protocol?: string
    protocol: *(*(*(*(defaults.evenMore | _|_) | defaults.more) | defaults.user) | defaults.k8s) | _
}

examples: [string]: #A

examples: eg0: defaults: {
}


examples: eg1: defaults: {
    k8s: "test"
}

examples: eg2: defaults: {
    k8s: "test"
    user: "user"
}

examples: eg3: defaults: {
    user: "user"
    evenMore: "something"
}

examples: eg3: {
    defaults: {
        user: "user"
        evenMore: "something"
    }
    protocol: "rubbish"
}

Gives:

examples: {
	eg0: {
		defaults: {}
		protocol: string
	}
	eg1: {
		defaults: {
			k8s: "test"
		}
		protocol: "test"
	}
	eg2: {
		defaults: {
			k8s:  "test"
			user: "user"
		}
		protocol: "user"
	}
	eg3: {
		defaults: {
			user:     "user"
			evenMore: "something"
		}
		protocol: "rubbish"
	}
}

Playground link

However, it would be good to get some more details on the problem you are trying to solve in your "opinion-based layer system", because that will really help to inform whether we can/should do more in CUE the language to help this sort of pattern. Can you flesh things out a bit more in pseudo code? Is @zzh8829's approach to layers close to what you want? If evenMoreDefaults does not specify a default for a field, do you want to fall through to the next layer? Or is it the case that you want to choose which profile of defaults you want to use?