I prefer option (3) - invariant return types. Actually, return type compatibility check should follow all the rules for parameter type compatibility check (may be even reuse or share the code). This solution may be implemented efficiently and consistently. It also must be enough for 99% use cases.
Thanks. Dmitry. On Thu, Nov 27, 2014 at 1:46 PM, Rowan Collins <rowan.coll...@gmail.com> wrote: > Levi Morrison wrote on 25/11/2014 17:08: > >> 1. Do covariant return types; check them at definition time >> 2. Do covariant return types; check them at runtime >> 3. Do invariant return types; check them at definition time >> > > I guess there's also option 4 - do "weak invariance", as we do with > parameters: any combination of types is actually allowed, but any variance > raises an E_STRICT notice. (This is only true with class inheritance; > interface implementation is strictly invariant, raising a fatal error if > the declaration is not typehinted identically.) > > I think my preference would be to implement return types with strict > invariance (option 3) initially, in order to keep the implementation and > discussion simple, and get the syntax baked into the language. > > Then immediately look into solutions for covariant return types, and > possibly also contravariant parameter types (relaxing the fatals for > interface implementation, and maybe raising the remaining cases above > E_STRICT for class inheritance). > > If a good solution and implementation can be found in time for 7.0, then > all the better, but if not, it can be added in 7.1, and no code written for > the hints added in 7.0 would fail. > > Regards, > -- > Rowan Collins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
