Bring new features from Symfony 3/4/5/6/7 into our container

These changes can not be implemented quick enough!

Whilst i think it is enabled by default by virtue of using the dependency injection component >3.3 it is the Drupal yaml wrappers etc that stop this functionality being available.

Does it make sense to support _instanceof?
https://symfony.com/doc/current/service_container/3.3-di-changes.html#au...

Drupal's container and YamlFileLoader have not changed much since 8.0.0 and lack these new features

The reason of maintaining own Yaml loader was to avoid dependency on Symfony Config component. Maybe today we can revise that decision?

The Config component is quite a big can of worms on its own : what would it actually gain us ? Do you really want to add SF-style config trees on top of our own CMI ?

I wanted to answer "how would this affect performance"

In short dev may be a improvement, production no so much. Me quietly giggling -- the last paragraph could be written with Drupal in mind.

https://symfony.com/doc/current/service_container/3.3-di-changes.html

What about Performance¶
Symfony is unique because it has a compiled container. This means that there is no runtime performance impact for using any of these features. That's also why the autowiring system can give you such clear errors.

However, there is some performance impact in the dev environment. Most importantly, your container will likely be rebuilt more often when you modify your service classes. This is because it needs to rebuild whenever you add a new argument to a service, or add an interface to your class that should be autoconfigured.

In very big projects, this may be a problem. If it is, you can always opt to not use autowiring. If you think the cache rebuilding system could be smarter in some situation, please open an issue!

Adding #3049525: Enable service autowiring by adding interface aliases to core service definitions

Do you really want to add SF-style config trees on top of our own CMI ?

We don't have to use it. Just add symfony/config as a dependency and use the original Yaml loader. This would help us to resolve issues like following.

• #3025714: Enable modules to define multiple services.yml files [Patch Inside]
• #3021899: Support resource key in services.yml
• #3021898: Support _defaults key in service.yml files for public, tags and autowire settings
• #3021803: Document and add tests for service autowiring
• #3049663: Support anonymous services

Im with Chi on this. We can Drupalise this all we want but there is a real fundamental issue we're all missing here.

We (the core dev's) chose to use symfony/dependency-injection. symfony/dependency-injection as a package has a set of dependencies and development dependencies (symfony/config being one of those). It is not for us to pick and choose which depdencies we want to use, and which we want to exclude. A dependency is a dependency is a dependency. If we want to use the dependency injection component, then we have to accept and include of all it's dependencies where required. If we are not happy with the dependencies of a package then we must choose another package to use in its place.

By doctoring underlying components you're causing headaches for all of us developers.
Common scenario:

• I review symfony docs for how and what can be done with a component
• I implement according to symfony docs
• Doesn't work
• Review documentation/check implementation x20
• Dig around in Drupal core.. find an undocumentated Drupalism has reduced component functionality..

I think from the above you can feel my frustrations. This needs to be sorted out.

Removed
#3021803: Document and add tests for service autowiring
#3021898: Support _defaults key in service.yml files for public, tags and autowire settings

Added
#3295751: Autowire core services that do not require explicit configuration

Symfony 6 also brings some exciting features like autowiring via PHP 8 attributes.

It does not fit in 9.5

Since we're adding interface aliases to core modules, would it make sense to start doing the same for contrib modules? And if so, for all services including things like event subscribers, or just services that are useful to other modules?

Since we're adding interface aliases to core modules, would it make sense to start doing the same for contrib modules?

To extend this question:

I see for now, in core, we are keeping the string service ids, and are only adding interface names as aliases.
For existing services this makes sense, because changing the existing service name would break BC.

In symfony, it is possible to use a class name instead of a custom service id.
This even seems to be the standard now, according to https://symfony.com/doc/current/service_container.html#creating-configur....

Automatic Service Loading in services.yaml

The documentation assumes you're using the following service configuration, which is the default config for a new project:

So the question is, should we adopt or allow using class names as service names in our conventions for contrib and for new services in core, or should we stick to custom string ids?

Beyond autowiring, we have a small issue in the URL generator not respecting the Unicode property of route regexps #3369925: Support Unicode regular expressions in routes, from Symfony 4.3.