I actually do like the idea of Generics, but the more I think about it, it's not the problem
here. Everyone should absolutely catch up on Larry Garfield’s Pattern Matching RFC. It could be
the key for generics (the is operator). The problem is making "array interfaces" a thing.
Larry said he probably wouldn’t add support in this version for array types, but I think that’s
a mistake. We should define a direction for what we would pass to new Array<T> .
I love Casper Lanemeijer’s syntax suggestion with some changes:
interface iArrayA ['a' => string ]
interface iArrayB implements iArrayA ['b' => string, 'c' => ?string ]
$array = iArrayA [
‘a’ => ‘hello'
];
// reads the same as a typecast
$array = (iArrayA) [
‘a’ => ‘hello'
];
// it’s essentially like a typecast, which should probably be allowed. If the set of possible
values needs to increase a typecast would do it.
class A {
public iArrayB $array = [
‘a’ => ‘hello’,
‘b’ => ‘world'
];
}
Best,
Richard Miles
> Begin forwarded message:
>
> From: Bilge <[email protected]>
> Subject: Re: [PHP-DEV] [Initial Feedback] Typed Arrays
> Date: June 26, 2024 at 3:04:30 PM MDT
> To: [email protected]
>
> On 26/06/2024 21:56, Casper Langemeijer wrote:
>>> Generics or bust.
>>
>> I do not understand the reasoning behind that. Is it because we really want generics, but
>> when the 95% use-case is solved we fear that there would not be enough momentum to get that?
>> I'd love to have generics too, but a very simple array syntax would in my opinion still add a
>> lot of value, even if we already had generics.
> It's not that there wouldn't be enough momentum; if anything, a successful typed
> arrays PR could give rise to such momentum. If it were possible to have typed arrays that were fully
> compatible with an (imagined) generics specification then I would be all for it. The problem is, how
> can we ever ensure compatibility with something that doesn't exist?
>
> It seems to me we either solve is problem properly (with generics) or not at all.
>
> Cheers,
> Bilge
>