Sorry, it looks like I've replied to Marco only.
About use case, we use it to specify types in standardized fashion:
if (!$value instanceof Foo) {
> throw InvalidArgumentException::unexpectedType($value, Foo::class);
> }
> if (!\is_int($value)) {
> throw new InvalidArgumentException::unexpectedType($value,
> \int::class);
> }
>
> $converter->convert($value, \int::class);
I also said that it might have some benefits for generic types:
I don't disagree with you, but it's already supported right now, so what
> I'm only proposing to make it consistent.
> Looking forward, supporting name resolution for primitive may have some
> benefits for generic types
> <https://github.com/PHPGenerics/php-generics-rfc/issues/20#issuecomment-407600337>
> .
Beside this, deprecating it now would represent a BC break, right?
Em seg, 1 de out de 2018 às 10:15, Rowan Collins <rowan.coll...@gmail.com>
escreveu:
> On Mon, 1 Oct 2018 at 13:24, Marcos Passos <marcospassos....@gmail.com>
> wrote:
>
>>
>> You can also see it as a language construct that expects a type at the
>> left-hand side of the name resolution operator. In that sense, primitive
>> types are perfectly valid.
>>
>
>
> While I can see that as an interpretation, it doesn't make a lot of sense:
>
> - the keyword "class" implies that this will always return a class name;
> it is the static equivalent of get_class(), which does not support
> non-objects
> - if instead it was resolving a "type", you might expect it to return the
> same values as gettype(), which for any object is simply the string "object"
> - the main purpose of the feature is to resolve namespace lookups and
> aliases, but basic types are not subject to namespaces; in other words,
> "int::class" can only ever return "int"
>
> As Marco says, if you have a use case where allowing this is helpful,
> please share it, and we can discuss if this, or some new related feature
> (e.g. "array::type"), would be worth supporting.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
