In general this is okay as impl, but im a bit afraid of the impact. wouldn't this mean that nullable needs to manually applied everywhere? TBH this is a very difficult thing for me because it would mean that pretty much most schemas would need to accept null. While functionally correct, Im afraid of implications on the schemas and the generators.

Wouldn't another choice be that we have the value return of null be equivalent to an empty value? As in, if a null value is discovered, that it gets inferred to be the zero value? for example, a field that is a []string, and gets set to null from an expression, could be [] as a value?

Happy to hear your thoughts

1. I wasnt sure if we would want to have this automatically applied, but thinking about this in the OCM context, I don't know what should break by automatically allowing null for pointer values
2. I would not allow this by default, cause it could really introduce some behaviour we might not want. But, we could opt-in this by using optional here like:

type test struct {
  //+optional
  MyVal int `json:myVal`
 }

{
  "myVal":null
}

could result in
myVal=0

If there is no +optional, I would want the validation to fail.

WDYT @jakobmoellerdev

I think optional is not a good choice because it is the equivalent of omitempty to stay consistent with kubebuilder syntax

I think optional is not a good choice because it is the equivalent of omitempty to stay consistent with kubebuilder syntax

ok let me focus on the nullable pointer implementation first (without nullable)
let's discuss the value defaulting in a follow up

now all pointers support null by default

I added omitempty (+optional before) back to the game. Based on @jakobmoellerdev comment, kubebuilder favors omitempty over the old +optional decorator https://book.kubebuilder.io/reference/markers

the reason:

• we do not want to allow null for every pointer, e.g. Repository in Transform spec as well as input and output
• I still think the impact of null-by-default for pointers is too wide and might introduce unwanted behaviour
• we should actively decide, if we want to allow null for pointers

I think you missed the mark here. I was saying that omitempty is the equivalent of having no value and is also equivalent to +optional. Thus adding "nullable" to the behavior is not correct: just because a value is optional does not mean it is nullable.

From above my suggestion was

Wouldn't another choice be that we have the value return of null be equivalent to an empty value? As in, if a null value is discovered, that it gets inferred to be the zero value? for example, a field that is a []string, and gets set to null from an expression, could be [] as a value?

This is still not happening and you rely on adjusting the schema instead.

We will postpone this, this needs more discussions - related PR kubernetes-sigs/kro#1003