What about using array_replace instead ? It would be clearer imo.

There is a difference between the removed and the new code : any pre-existingnull value was overridden previously, but isn't anymore. I don't if that's a bug for or a regression. It would be great to have a test case ensure the correct behavior is tested.

@GuilhemN Yeah it would be clearer since this operator isn't widely used, but array_replace is also slower. I try to make my changes without performance impact. I think we can instead solve this by adding // comment to indicate what we are doing if you wish. What do you guys think?

@nicolas-grekas Yep I'm aware of that. I'll let you guys decide what is correct behaviour, then I will modify my patch appropriately, even if it's only adding the test case. IMO duplicate keys are not supposed to be overwriting any previously set values. In 3.2 there was even deprecated ability to specify duplicate keys. I can even modify this to make this trigger deprecation instead, however I don't know what message is appropriate, since I'm not familiar what does this block of parser do.

The correct behavior is dictated by the yaml spec.@xabbuh or@GuilhemN any hint on that topic?

@nicolas-grekas I didn't check but I don't see any good reason justifiing a different behavior fornull so I think it's a mistake here.

Nothing is said aboutnull so I understand that it should behave the same as any other value.

@gadelat can you add a test case in this direction please?

👍 This will solve the initial overlook that didn't take into account thatisset() returnsfalse fornull values.

Status: Reviewed

Thank you @gadelat.