how canpublic string $username; ever be null in the first place?

@ro0NL when hydrating objects from external source/input, e.g a submitted form or a deserialized payload to be validated.

AFAIK you'll hitUncaught TypeError: Typed property Class::$prop must be string, null used in general. The only reason this works is duePropertyMetadata::getPropertyValue i figured.

Perhaps the ship has sailed, and this complements our PHP74 support in general. But IMHO one should validate the raw payload, before hydrating a non-nullable property.

Not in the context of the form given#36492.
But I agree for validating the raw payload as a preference, however this is still a shortcut for not null properties that could be read as null for partially hydrated objects or when relying onhttps://github.com/symfony/symfony/blob/master/src/Symfony/Component/Validator/Validator/ValidatorInterface.php#L55 to validate the raw payload.

This allows to decouple model from hydrators, and explicitly declare not nullable props with the type instead of a not null constraint.
The naming is bit confusing though. What about@Assert\NotNullableTypes?

Or@Assert\Initialized?

does that meanAssert\Initialized still translates toNotNull constraints, based on the fact we also getnull from properties in uninitialized state? Doesnt that trigger side effects if the value is trulynull?

In general i likeAssert\Initialized as a class constraint, to ensure all properties areinitialized.

However, IMHO it's developer concern. De facto, objects shouldnt be in uninitialized state after construct.

I'm not sure I like this StrictTypes constraint. What do you think@xabbuh?

Closing for now as the PR is stale. Feel free to reopen when you have time. Thank you.