Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112862
MIME-Version: 1.0
References: <CAF+90c8Euq9nTMeoeUJ3a6s3wyj_DqbOeXoh07oDeUy6PeCefA@mail.gmail.com>
 <CAKuGYLRJHQ0s6yhNVYnYg+eEFiE_cEyKd6ChO5eTSKTxNUgmsg@mail.gmail.com>
In-Reply-To: <CAKuGYLRJHQ0s6yhNVYnYg+eEFiE_cEyKd6ChO5eTSKTxNUgmsg@mail.gmail.com>
Date: Wed, 13 Jan 2021 10:38:55 +0100
Message-ID: <CAPyj-LAciNKHmvW28ZJ3rda3RC-f023kLoneeLg6FAJQ2sQi4g@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] Allow object keys in arrays
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Matthew

On Wed, Jan 13, 2021 at 7:15 AM Matthew Brown <matthewmatthew@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