Couldtrue be a better default here? How frequent is to clear errors for root form only? I think most of the time it happens inside a child field.

There is an issue about the same default butgetErrors($deep = false) method#25738 and was reported as confusing.

I don't have a strong preference either way, but I do think the default value here should matchgetErrors().

Is it possible to have a clearable form type nested in a non-clearable one?

Yes, buttons are not clearable and they could be included in a form that is clearable.

The question was the other way round. As the code here stops the traversal of the form tree as soon as a non-clearable form type is encountered, it will not clear clearable fields nested in non-clearable ones.

The only non-clearable fields we have in the symfony core are buttons that can't have children.

This could append in libraries but then it can be considered the responsibility of the library to implement this interface if needed.

Yeah, I know. But why risk it, if the change would be fairly easy?

It would mean children won't be able to implement custom error cleaning logic, that's something someone might want to do.

Yeah, I know. But why risk it, if the change would be fairly easy?

We can't addclearErrors() toFormInterface as that would be a BC break. And even if we could, that would require us to implementclearErrors() on theButton class, which makes no sense because buttons can't have errors or children - it'll either be a pointless no-op or throw aBadMethodCallException.

I wasn't hinting at implementing it everywhere, but decoupling the traversal of the form tree from the actual form field clearing.

Like the visitor pattern, if you will.
But this edge case doesn't seem too severe.

Let's add type hint to argumentpublic function clearErrors(bool $deep = false);.
But please don't add: self, we already had discussion on this (#27190 (comment)).

Added and amended! Thanks for the feedback 👍

You should type hint: self here

@HeahDude , we had a discussion on return types here:#27190 (comment)
The problem will be that when using->clearErrors()-> on actual object implementing this interface, the IDE will not show any other methods in autocomplete, because: self is not: static. So from my opinion it's much better to leave@return $this phpdoc.

You can leave the@return $this phpdoc and add: self at the same time. AFAIK phpdoc takes precedence with type declaration for IDE auto completion, this means we would get both the correct auto completion and strictness at the language level (that an instance of the interface is returned).

okay, then let's use: self 😄

Using: self on an interface forces theForm subclass implementation to use a: ClearableErrorsInterace typehint:

Fatal error: Declaration of Symfony\Component\Form\Form::clearErrors(bool $deep = false): Symfony\Component\Form\Form must be compatible with Symfony\Component\Form\ClearableErrorsInterface::clearErrors(bool $deep = false): Symfony\Component\Form\ClearableErrorsInterface in src/Symfony/Component/Form/Form.php on line 61

I'm not sure this is what we want.

AFAIK phpdoc takes precedence with type declaration for IDE auto completion

I could not get this working in the latest version of PhpStorm:

Furthermore, I could not find any other interfaces in Symfony with a: self return type hint. For these reasons I think we should leave it as-is.

The fact that we don't have any existing interfaces with aself return type hint is probably because we couldn't make use of them before Symfony 4. So I would still use it here and use the docblock to be more precise.

Symfony code base uses capital style to comment params.

Fixed, amended, and force-pushed :) Thanks for catching that!

missing return type hint (same in the interface)

actually I am not even sure if it makes sense that this method returns anything

All form methods are chainable, so it makes sense to keep it here.

@xabbuh see#27580 (comment)

I think it's time to decide this once and for all inhttps://symfony.com/doc/current/contributing/code/standards.html

Well, fluent methods are a pain for return types. so even if we want to have as much return types as possible for new APIs, I'm not sure we want them for fluent APIs.

@xabbuh@stof I have removedreturn $this; from the method for a few reasons:

1. You're right, this method doesn't really need to be chainable.
2. ClearableTokenStorageInterface (a new and similar interface introduced in SF4) does not return anything, so perhaps we should be consistent here.
3. It seems like there's no definitive rule on how to type hint interface methods that return$this /self. I don't want to set a bad precedent here.

Then you should add: void in interface and class

But I am for consistency withFormInterface which has@return $this on methods likeaddError. Although I agree that fluent interfaces are pain.

I've changed my mind and addedreturn $this; back in. I could see developers wanting to call$form->clearErrors()->createView() so this definitely has value.

The last unanswered question is what to do about return types. Our ultimate goal is to haveForm::clearErrors() return that originalForm instance. Here's what theReturn Type Declarations RFC has to say about our current situation:

The enforcement of the declared return type during inheritance is invariant; this means that when a sub-type overrides a parent method then the return type of the child must exactly match the parent and may not be omitted.

This is why using: self on the interface requires theForm method to use: ClearableErrorsInterface which is not ideal.

However, the RFC goes on to say:

If the parent does not declare a return type then the child is allowed to declare one.

Because this is a valid approach, I thinkomitting the return type from the interface but using: self on theForm makes the most sense in this situation:

1. A return type on the interface is pointless because there are literally no other methods onClearableErrorsInterface. Is somebody really going to call$form->clearErrors()->clearErrors()->clearErrors()?
2. This gives us the functionality we want (accurate return type hint onForm) despite PHP's current limitations with invariant return types.

@xabbuh I have added a: self return type here per your request. See#27580 (comment) for an explanation of why I didn't also add a return type to the interface. Let me know your thoughts :)