Hi Matthew
On Wed, Jan 13, 2021 at 7:15 AM Matthew Brown <matthewmatt...@gmail.com> wrote:
>
> This proposal is interesting, and I see why the enum proposal makes it
> useful.
>
> Supporting this will mean a small amount of work for me (assuming it
> passes) and other static analysis tools, but I don't want that to factor
> into anyone's decision.
>
> I am curious, though, whether the scope of this RFC could be narrowed to
> just allowing enum cases as keys? That might avoid issues with objects that
> cannot be cast to string.
The enum RFC currently does not propose auto-implementing __toString()
and actually forbids implementing __toString() manually in case we
want to add some type of coercion at some point. While we could change
that, I do think it introduces some inconsistencies.
enum Foo: string {
case Bar = 'bar';
}
var_dump(Foo::Bar . 'baz'); // barbaz
enum Foo: int {
case Bar = 1;
}
var_dump(Foo::Bar + 2); // Type error
// Will require Foo::Bar->value to work
We intentionally removed auto-coercion from enums because the rules
are complicated and not clear-cut, and type strictness is what the
language generally seems to be striving towards.
That is not to say narrowing object keys to enums is a bad idea. I
think that might be worth considering for other reasons.
Ilija
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
