@soullivaneuh the issue with that is that it cannot be implemented easily (it requires some parsing of the string, and looping over the array rther than just checking the value).

There is a workaround though:

$resolver->setAllowedTypes('attachments', 'array')
    ->setAllowedValues('attachments', function (array $attachments) {
        // we already know it is an array as types are validated first

        foreach ($attachments as $attachment) {
            if (!$attachment instanceof \Swift_Attachment) {
                return false;
            }
        }

        return true;
    });

Thanks for the workaround. I already did something similar but with a normalizer.

I let this issue open if somebody got some courage to handle it. ;-)

@stof I've sent a PR that would enable typed array support, I've added a couple of simple test cases ('\DateTime[]' and int[][]), both of which seem to work just fine

@EVODelavega Maybe you can propose a PR. Not sure if it should be on 2.7 or 2.8.

@soullivaneuh I've taken 2.8 as a starting point, but I should imagine I can patch 2.7 quite easily anyway, so if the maintainers want, I can create a PR, or mail a patch for 2.7 all the same

@soullivaneuh new features cannot be added in maintenance branches. So there is no discussion about 2.7 or 2.8: it cannot be 2.7 (you could discuss it between 2.8 and 3.0, but we already have the answer for this: if it is BC it goes in 2.x)

Maybe this problem would also be solved with #4833, i.e. if you consider an array of something as an suboption with any key and it's corresponding type.

@Tobion I don't think it can. Suboptions work fine when you know the expected children and can configure validation for them. This case is for a list of similar nodes.
If you look at these concepts in the Config Definition component, this is the difference between an array node and a prototyped array node.

I know, but the same thing already is going on when not using suboptions. If you want to allow any option, you have to read the passed options and make them known to the resolver. The same would apply for suboptions. The question is only if we need some special handling considering these options would have an integer key.

@Tobion I thought about ways to implement what you're hinting at, but decided not to do that because that, IMO, is beyond the scope of allowed types. Pre-defining a specific structure, including keys existing or not, and the types of the values they hold is something best left to a custom validator, or in a normalizer.

On the other hand, you could create a wrapper class that defines the given structure in full, and just write $resolver->setAllowedTypes('foo', 'YourClass'); or, if my PR gets merged $resolver->setAllowedTypes('foo', 'YourClass[]');

@Tobion associative arrays don't mean it is a set of keys defined by the form type. The option could be expecting an arbitrary map.
And this cannot be determined automatically because there is not enough info in the value to know how it is expected to be used (and even less info when you know that the info is here to be validated, and may not even be from the expected format)