[OptionsResolver] Options not provided by user triggers deprecation

[ro0NL]

Description
Since 4.2 OptionsResolver can deprecate options, however the deprecation is triggered from offsetGet()

symfony/src/Symfony/Component/OptionsResolver/OptionsResolver.php

Line 943 in 9bec1fc

@trigger_error(strtr($deprecationMessage, array('%name%' => $option)), E_USER_DEPRECATED);

Im not sure about this, it causes the deprecation to trigger without even being provided by the user (i.e. when accessing the default value). Shouldnt it be moved to resolve() instead?

ref #27277 cc @yceruto

[ro0NL]

i confused array $options and Options $options. Of course only in case of the latter the deprecation triggers when accessing the option, but this can still happen e.g. in SF core (e.g. when referenced from a default value closure in another option)

So no real issue so far, but maybe it needs special API like offsetGet($option, $triggerDeprecation = false) sooner or later.

[yceruto]

[OptionsResolver] Options not provided by user triggers deprecation

I agree, but this behavior is expected also for ppls who use a deprecated option during a lazy evaluation or normalization of another option. In those cases, they should always notice the deprecation message (even, if no value is provided).

Tomorrow I'll take a look,
Cheers!

[ro0NL]

See #28860 that includes a patch

IMHO setDefaults belongs to the definition side (along with setDeprecated), and only consuming deprecated options should trigger

[yceruto]

See the proposal to solve it #28878

[stof]

@ro0NL if you have a lazy default value using the value of another deprecated option, you need to be warned, to know you need to migrate your callable (but there should be a way to opt-out of the deprecation to be able to write a BC layer)