Skip to content

Make Option covariant#26

Closed
devnix wants to merge 1 commit intophp-standard-library:2.0.xfrom
devnix:option-covariant
Closed

Make Option covariant#26
devnix wants to merge 1 commit intophp-standard-library:2.0.xfrom
devnix:option-covariant

Conversation

@devnix
Copy link
Copy Markdown
Contributor

@devnix devnix commented Dec 2, 2025

No description provided.

@ondrejmirtes
Copy link
Copy Markdown
Collaborator

I'd only merge this if the original was covariant as well: https://github.com/azjezz/psl/blob/next/src/Psl/Option/Option.php

Otherwise it's not safe.

@devnix
Copy link
Copy Markdown
Contributor Author

devnix commented Dec 2, 2025

It looks like it maybe shouldn't be covariant due to methods like or(), orElse(), compare() and equals().

There are cases that I'm unsure about how to handle, for example:

Parameter ...  of method Foo::__invoke() expects Psl\Option\Option<non-empty-list<Bar>>,
Psl\Option\Option<array{Bar}> given.

I'm not sure about if it's a problem that should be handled with call-site variance (expecting Psl\Option\Option<covariant non-empty-list<Bar>> or if native subtypes are treated as class/interface subtypes, at least in terms of variance and they should not.

I'm not sure at all about that last point, as I'm still understanding variance, but to me array{Bar} should be a valid param for non-empty-list<Bar>. Is this case related to phpstan/phpstan#6732 (comment)?

@ondrejmirtes
Copy link
Copy Markdown
Collaborator

Hard to judge without a code sample on phpstan.org/try

@devnix
Copy link
Copy Markdown
Contributor Author

devnix commented Dec 3, 2025

I'll close the pull request for now and open an issue with any specific example if I get an reproducer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants