Maybe we could use a yaml tag for default values (or other non-service keys) instead and keep allowing anything for service names.

We wondered about tags for eg_defaults in#21194, but that didn't look good. What would it look like to you?

Probably something like this

services:defaults:!defaultpublic:falseFoo\Bar:[@foo]

Any service tagged with default would be used as default instead of a service. And the key would be ignored.

That's what I meant by:

that didn't look good

I keep this opinion :)

Yeah I don't like it that much, but using underscore-names to convey special meanings looks to much like a hack to me to like it.

Is it too late to create a new config option calledservices_defaults ? It could convey its meaning better and it'd remove the need for hacks and for the YAML/XML unparity:

services_defaults:public:falseservices:Foo\Bar:[@foo]

@javiereguiluz this discussion already happened, see#21071 :)

@javiereguiluz this isalso a BC break, as it makes this key forbidden for DI extensions (and it is much harder to write a BC layer, as we would be unable to detect this case as the DI extension could expose a config similar to our defaults)

Thank you@nicolas-grekas.