Dominic Grostate wrote on 29/04/2016 17:45:
This means then that to use a subtype for the type argument, it is
safe for the function to READ the argument, but unsafe to WRITE to it.
Conversely. If the function accepted List<Integer>, but was
theoretically given List<Number>, WRITING would be safe, but READING
wouldn't.
Precisely. If you read the blog post linked earlier [1], that's exactly
how they describe it.
Given this, it doesn't matter how it's done, both scenarios are prone
to error, and the only options are to either accept that or disallow it.
The only safe *default* is to disallow it.
However, for a particular implementation, you as the author may know
that you are only ever going to write to a particular parameter, and can
therefore safely allow that parameter to be "too broad"; or you may know
that you are only ever going to read from it, so can safely allow it to
be "too narrow". This requires extra syntax in the language, and is
fiddly to use right, so should probably be left out of the first
implementation and considered later.
This is exactly what Hack did, adding a class-level annotation of <+T>
or <-T> for read-only or write-only parameters, respectively, to their
existing implementation.
[1]
http://hhvm.com/blog/9215/covariance-contravariance-and-super-type-constraints
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
