...

Has there ever been a discussion about adding some of those features

syntactically, but ignoring them during runtime?

That's what Hack does, and one of the main reasons we dropped Hack in

favor of PHP.

PHP is a reflective language - if we add e.g. generics or property

type-hints, omitting run-time reflection and/or run-time type-checks

would be inconsistent with PHP as a language in general.

Inconsistencies in a language are surprising and generally "bad" - if

type-hints lead to run-time type-checks, it's natural to expect that

to work predictably no matter where you type-hint. You shouldn't have

to learn where or when type-hints actually work at run-time and where

they don't.

Similarly, if type-hints are reflected, it's natural to expect all

type-hints to exist in the reflection model somewhere, anywhere that

type-hinting is possible. You shouldn't have to search the manual to

learn that type-hints aren't reflected for properties for some reason,

perhaps because it just hasn't been implemented yet.

Much of the "good" that we expect to be able to accomplish with

generics, for example, won't be possible (or won't make sense) without

being consistently reflected and run-time type-checked.

For example, in a DI container, I'd expect to be able to do something like this:

class Container { public function get<T>(?string $name): T { // ... } // ... }

When calling get(), I'd expect a type-check for the the generic

return-type T, to protect me against internal errors in the Container

implementation - if it returns the wrong type, I want it to fail

immediately at that point, rather than potentially exiting the

call-stack that made this error traceable, making this extremely

difficult to debug.

Similarly, if we had property type-hints:

class Foo { int $bar; } $foo = new Foo(); $foo->bar = "oops";

Here, I'd expect a type-check when assigning to $bar - omitting that

would be extremely bad, as, very likely, by the time something else

fails because this object is in an invalid state, we've exited the

call stack where the bad value was assigned, making this potentially

very difficult to debug.

I'd also expect to be able to reflect on the property-types in a DI

container, or perhaps in a class that maps form post-data to

properties and performs conversions, etc.

I'm the author of the generics RFC and one of the property-type RFCs,

and both of those RFCs call for both reflection and run-time

type-checking, for the sake of keeping the language consistent.

Hack made some very regrettable decisions in this area, and ultimately

those features were useful at design-time only, for IDE-support - but

we have php-doc for that purpose, and in my opinion, adding those

features before (or unless) we're willing/able to also make them work

consistently with the language, does more harm than good. Making these

features appear to be language features, when in fact that they're

only implemented in the parser and ignored by the interpreter, would

make for an extremely confusing experience.