What do you want to achieve ? This is the normal behavior of the empty() function: false is considered empty like '0' and some others like the empty string.

For scalar nodes, if you want to invalidate empty strings but keep '0' valid, you can use this instead

$rootNode
    ->children()
        ->scalarNode('scalar')
        ->isRequired()
        ->validate()
            ->ifTrue(function ($v) {return '' === $v;})
            ->thenInvalid('Cannot be the empty string')
         ->end()
    ->end();

@florianv I understand how empty() works, and I understand how to work around this issue.

The main issue here, is that one does expect the functionality of "cannotBeEmpty" to work only in certain cases.. on a booleanNode, using either true or false are indeed values, and from a user point of view, you have complied to this rule. The fact that is uses empty() is an implementation detail (a very deep implementation detail), that is not obvious, documented or otherwise from the outside world.

I would propose that cannotBeEmpty() either be documented better to emphasise that cannotBeEmpty might use empty() as an implementation detail, and therefore even supplying a perfectly correct value would still result in an exception, OR change the implementation to make sure that bool(false) or bool(true) will indeed work, as the name implies.

(there are precedents in this matter btw.. there is a FormUtil:isEmpty that evaluates empty arrays, and boolean(0) to true. In fact, it will only return false when data === null or when data === empty string.
I think such a isEmpty() method this would be a much better match in this case as well..

OR change the implementation to make sure that bool(false) or bool(true) will indeed work, as the name implies

Can you clarify what does "empty bool" mean for you? What do you expect from this constraint?

I'd expect an exception as cannotBeEmpty makes no sense with bool for me, i.e. it looks like wrong config definition.

Why is that? Because cannotBeEmpty implies that you must specify a value. 'False' is indeed a value, even though an implementation decided otherwise.

It would be perfectly valid to ask the user to set an option on the config, which they must explicitly do so, without a default value. Imho, it makes no sense to me to be able to use cannotbeempty on a boolean, where you can only supply the value 'true'.

I would propose this to change. In a boolean context false is a perfectly valid option (in fact, it makes up 50% of the valid options).

Why is that? Because cannotBeEmpty implies that you must specify a value.

isRequired does it.

Yes. You are correct. Cannotbeempty implies that the value cannot be empty. Specifying a value false, is in fact suplying a value. The confusing part is that false is in this case threated as an empty. I understand that this is due to the implementation if empty(), but imho its not the same thing in this context

I think @jaytaph is right and that this can be expanded to include any scalar value that the empty() function considers to be empty but is technically not (false, 0, 0.0, "0").

I agree that the current implementation is wrong. It's not only with false, but also with strings or numbers (the ones @SoboLAN showed). numerOfX: 0 should not be invalid for an integer node with ->cannotBeEmpty(). Currently, it is.

see #15170