Re: [RFC] Always generate fatal error for incompatible method signatures

> If you want the reverse to be true, then your code has bugs waiting to > show themselves I don’t, I just don’t want fatal errors in production when I upgrade library I extend. Let me keep logging such issues and fix them later, instead of producing hard crash for customers. > The earlier we can catch these bugs, the better. What prevents somebody to catch warnings? This RFC is about hard crash that I disagree with. This type of issue is problematic only when expecting parent but injecting child. > On 9. Apr 2019, at 17:35, Levi Morrison <levim@php.net> wrote: > > On Tue, Apr 9, 2019 at 9:00 AM Gabriel O <gadelat@gmail.com> wrote: >> >> I believe rfc deals with reverse situation >> >> On 9 April 2019 4:47:50 PM Dan Ackroyd <Danack@basereality.com> wrote: >> >>> On Tue, 9 Apr 2019 at 11:58, Gabriel O <gadelat@gmail.com> wrote: >>> >>>> And this RFC conveniently shows only big LSP violation examples like array >>>> -> int, but not widely used narrowing like mixed/object -> specific instance. >>> >>> >>> Type narrowing or contravariant parameters is properly supported for >>> PHP 7.4: >>> >>> https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters >>> , which is why this RFC doesn't need to cover them. >>> >>> cheers >>> Dan >>> Ack > > If you want the reverse to be true, then your code has bugs waiting to > show themselves. The earlier we can catch these bugs, the better. > > One thing to note is that return type information does permit > optimizations in some cases. For instance, I believe if a private > method has a return type constraint of int, then the optimizer can > rule out certain edge cases, and in some cases use type specialized > handlers. We can do these sorts of optimizations in more places if the > LSP issues are always errors, instead of warnings. > > So for both correctness and performance, I support this change.