must be changed to<4.1 when the4.0 branch is created

would need to be changed to~4.1

extendsType()? Same inUPGRADE-5.0.md andsrc/Symfony/Component/Form/CHANGELOG.md

in Symfony 5.0? Same insrc/Symfony/Component/Form/CHANGELOG.md

What do you think aboutreturn self::extendsType(); to make clearer the migration path?

why not keeping@expectedException and@expectedExceptionMessage ?

@expectedDeprecation would not be evaluated then

you must throw an exception here, telling to implement the other method or to override this one, because returningnull is not allowed.

we often add the to-be-added method as commented code in the interface

using@method seems like a new approach. works both I guess

This validation prevents to use different instances of the same class to be used for different extensions. So it prevents the only advantage ofextended_type attribute that I mentioned in#24530 (comment) as people will be forced to implement the method in 5.0 when its part of the interface. So they need to return an empty array and then overwrite it with the service attribute.

IMO we do not need the validation anymore as now both the registration and implementation uses getExtendedTypes. So there should not be a mismatch anymore unless you wire something wrong manually.

class FooBarTypeExtensionextends AbstractTypeExtension{publicfunction__construct(string$type)    {    }publicstaticfunctiongetExtendedTypes():iterable    {returnarray(            FooType::class,            BarType::class,        );    }}

App\Form\FooBarTypeExtension:arguments:['foo']tags:        -name:form.type_extensionextended_type:FooTypeApp\Form\FooBarTypeExtension:arguments:['bar']tags:        -name:form.type_extensionextended_type:BarType

Do I understand correctly that you have something like this in mind?

Yes. By returning both types from getExtendedTypes, it actually works even with the validation. So I'm fine keeping it like this. But I think it would make more sense to remove the validation as it should not matter what is returned by getExtendedTypes if you set the extended_type attribute (and you might not even know that in advance if you create a dynamic form extension).

I wonder if we shouldn't rather deprecate theextended_type attribute too instead I could imagine that using it adds more confusion than an implementation wheregetExtendedTypes() is the single source of truth.

I agree that it potentially is complicating things for no real use-case. But I also like that it allows to configure extensions dynamically via DI (instead of hardcoding it into a class). As I said in#24530 (comment), its similar to the command attribute of the console.command tag. So it would be consistent to keep it. But I would not object to deprecate it as well.

Let's keep it for now. We can still consider to deprecate it later when we noticed that it adds too much confusion.

$extension->getExtendedType() would need to be replaced by$extendedTypes. But as said above, the whole thing could be removed.

WithgetExtendedType deprecated, all the calls that are still done to it need to use the new static method instead when it exists. E.g. in AbstractExtension that yceruto mentioned. And it should also trigger a deprecation message or is this done automatically?