Rebase needed after the whitespace PR

Rebased

The next step would be the support for the array{foo: string, bar?: int} syntax, but this might be a little bit more complicated and should be done in another PR anyways.

I don't think it will be necessary, as nested option definitions can currently handle that

It's great to have! However, I'm not sure adding support for anything other than array<string, X> is a good idea, as a shorter and simpler alternative is already supported

It's debatable:

First array<int, X> need to be supported because array<int, X> is not the same as X[] (which means array<int|string, X>). In the same way people might want a array<numeric, X> (but it feel weird).

Secondly, people might prefer one syntax over another, especially when dealing with multiple options with arrays:

• array<int|string, X> might be preferred over X[] because it's explicit...
• array might be preferred over X[] to always use array<> syntax with or without keys...

Also, if one day we plan to introduce more "types" like non-empty-string or positive-integer,
the current implementation will require no extra work to support them as array-key.

Or do you mean you're ok with keeping the current implementation but removing some tests @yceruto ?
I would like to offer a BC promise on the fact array<X> will stay valid because it's became an usual syntax for phpdoc.

This PR is mark as "Need works".

Friendly ping @yceruto just to be sure you saw my answer
#59442 (comment)

I'm unsure about the "work needed" atm since I'd like to support both array<X, Y> and array<Y>

I wonder if at some point it'd be easier to leverage the StringTypeResolver of TypeInfo, as it does what you're trying to achieve. The only downside it that it requires the phpstan/phpdoc-parser library to work.

I wonder if at some point it'd be easier to leverage the StringTypeResolver of TypeInfo, as it does what you're trying to achieve. The only downside it that it requires the phpstan/phpdoc-parser library to work.

Indeed that would be great. I didn't know such component already existed.
But is it possible without changing the constructor of OptionResolver ?

In the same way people might want a array<numeric, X>

Only strings or integers are supported anyway, so I'd throw an exception if anything other than string|int is configured as an array key.

I'm okay with full array<> support if there's no better way to define the array key.

In the same way people might want a array<numeric, X>

Only strings or integers are supported anyway, so I'd throw an exception if anything other than string|int is configured as an array key.

It's not only string or integer. You can also allow numeric.
And technically, 'long', 'integer', 'scalar' are working.
And any union of all these types should work too.

So adding a check would add some complexity with no real benefit, because if someone use

array<bool, int>

for instance, there will be already an exception since keys are not bool. "Expected bool, got int".
Which allow the developper to see his mistake.

In the same way that ->addAllowedType('foo', 'strin') will throw an exception, when using the option "Expected strin, got string".

The configuration validation as only interested if the validation was made on the addAllowedType call ; which is not the case (you're asking for doing it at the option resolving).

I can add a test with array<bool, int> if you want @yceruto to prove it

@VincentLanglet PHP arrays don't support anything else than integers or strings as array keys. numeric would allow floats, while they are not valid keys.
regarding integer, this is treated as an alias of int IIRC, so we would still support it for consistent.

@VincentLanglet PHP arrays don't support anything else than integers or strings as array keys. numeric would allow floats, while they are not valid keys. regarding integer, this is treated as an alias of int IIRC, so we would still support it for consistent.

The option resolver will be validating existing array-key.
So numeric won't allow floats since it's not possible to set a float as array key.
But it will accepts floats as array-key which is int|numeric-string and different from int|string because stricter.

I wonder if at some point it'd be easier to leverage the StringTypeResolver of TypeInfo, as it does what you're trying to achieve. The only downside it that it requires the phpstan/phpdoc-parser library to work.

Makes sense to me. Should we stop building another type parser in this component to look into this instead?

Maybe we can:

• if phpstan/phpdoc-parser is installed, leverage the TypeInfo component and process complex type strings
• otherwise, process only simple type strings (and throw a meaningful exception message telling to install phpstan/phpdoc-parser when a complex type is defined)

WDYT?

Maybe we can:

• if phpstan/phpdoc-parser is installed, leverage the TypeInfo component and process complex type strings
• otherwise, process only simple type strings (and throw a meaningful exception message telling to install phpstan/phpdoc-parser when a complex type is defined)

WDYT?

I agree.

Should I close this PR or array<> syntax is considered simple enough for being processed without phpstan/phpdoc-parser @yceruto @mtarld @chalasr ?

I would suggest reworking this PR according to the proposed plan :)

Maybe we can:

• if phpstan/phpdoc-parser is installed, leverage the TypeInfo component and process complex type strings
• otherwise, process only simple type strings (and throw a meaningful exception message telling to install phpstan/phpdoc->parser when a complex type is defined)

WDYT?

I agree too 👍