About the proposal itself of allowing `($expression)::class`, I'd be in favor.
> > > Den tor. 9. jan. 2020 kl. 22.41 skrev Mike Schinkel <m...@newclarity.net>: > > > > Traits are compiler assisted code copy/paste and not contracts (unlike > > interfaces), so there is no gain in having ::trait. > > It can already be referring to using ::class so it makes little sense to > disallow ::trait unless there is a different reason not to add another > ::keyword. > > Traits are symbols, so it is not unreasonable that there would be a way to > access it symbolically so that the reference can be type checked. > > One of my use-cases for referring to traits is to provide helpful hints in > error messages, i.e.: > Regarding the inclusion of new keywords with similar behavior of `:class`: Would `Interfaces\FooInterface::trait` or `Traits\FooTrait::interface` cause a run time error? If I'm not mistaken `::class` can't trigger error because it can't trigger autoload like `class_exists()` calls does. Currently `::class` can be used to resolve any name like `trim::class`. IMMO it would be weird to have `::class` with the current no autoload / error free behavior and then `::trait`, `::function` and `::interface` triggering autoload and emitting some error level. And also it would be weird to have `::trait`, `::function` and `::interface` with the same loose behavior as `::class`, in that case, it seems less surprising to have just `::class` everywhere instead. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
