Roland Franssen :)

> encouraging people to register symbols to the global namespace im not encouraging it generally :sweat_smile: but in this case i believe `\trigger_error` vs. `\trigger_deprecation` align perfectly the community was...

> There is really no difference if you import it: except you have to import it i agree with your POV, but im surprised SF apparently cant/shouldnt extend PHPs global...

see https://github.com/symfony/symfony/pull/31365 which was ultimately caused by https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Exceptional_reservations

> Unless this was intentionally removed? yes. Do you experience it as a bug?

ideally we preserve BC by deprecating removed entries first, but that's a data issue which isnt nessecarily covered by the current BC promise AFAIK :sweat_smile: > My thoughts would be...

would it be reasonable to consider a "compute json inline" approach, rather than end-users taking care of unique identifiers ```php $lazyJson = ['key' => fn() => yield from $heavy]; ```

we could array walk the structure first, thus keeping the unique placeholders an implementation detail.

the idea is to split the generators from the structure, preserving remaining logic. But this is an extra step yes, thus less ideal perhaps.

this is not about adding support for XML, YAML, etc. though i'd fundamentally agree it should be possible to add later ideally the parsing happens in a lazy manner, thus...

i understand if this is too disruptive also i realized for us the better path is to deserialize requests into dedicated (message) DTOs, and dispatch from there