I'm not sold by this change. Could you elaborate a bit more on when this would be useful?

It looks to me like a new feature intended to remove a deprecation notice.

Hi@yceruto, thanks for the feedback. You are absolutely right, thischanges an existing behaviour. My apologies for misclassifying it.

The use case I had in mind is to allow child classes to override a deprecation set by a parent class. Without this change, it's impossible for a child class to cancel a deprecation.

Imagine a baseFormType in a third-party bundle deprecates an option like 'hostname' in favor of 'host':

// In MyBundle/Form/BaseType.phppublicfunctionconfigureOptions(OptionsResolver$resolver){$resolver       ->setDefined(['hostname','host'])       ->setDeprecated('hostname','my/bundle','1.0','The option "%name%" is deprecated, use "host" instead.'       );}

Now, in a child class extending it, you might want to re-enable 'hostname' without deprecation (maybe for backward compatibility in a specific context):

// In src/Form/AppType.phppublicfunctionconfigureOptions(OptionsResolver$resolver){parent::configureOptions($resolver);// This call is the new behavior$resolver->setDeprecated('hostname','my/bundle','1.1','');// Should disable the prior deprecation}

Do you think this capability is a valuable addition? If so, I am happy toclose this PR and re-open it against the8.0 branch. Or, if you think this behavior is not desirable, I will close this PR entirely.

Please let me know what you think.

Hi, thanks for clarifying the use case. I don't think that change is needed though, you can already redefine the same option even if it's marked as deprecated. The resolver will apply your new definition, and you can simply ignore the deprecation triggered by the parent class. Once the deprecated option is eventually removed upstream, your redefinition will seamlessly take over without issues.

I'm still considering whether this is a valid use case, and why you can't use thehost option instead, since the deprecated option is handled entirely upstream.

Another alternative is to remove the option before redefining it, clearing any parent definition.

$resolver->remove('hostname');$resolver->define('hostname');

I just checked the remove method, and it seems we missed unsetting the deprecated option, if any. PR welcome!

I'm like Yonel. There need to be a real world use case and I'm not sure there's one at the moment. We might actually consider that an empty deprecation message should throw. If we did so, would any use case be impossible? I don't see when.

Hi@yceruto and@nicolas-grekas, thank you both for your feedback. You are right, my original use case was flawed. Using$resolver->remove('hostname') first is a much cleaner and more explicit way to override a parent's definition.

@nicolas-grekas To answer your question: I agree. After this discussion, and assumingremove() works correctly (which the new PR fixes), I don't see a real-world use case that becomes impossible.

I have just created the new PR to fixremove() as@yceruto suggested. You can find it here#62347

As this PR is not the correct approach, I am closing it.