Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106548 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 32430 invoked from network); 11 Aug 2019 19:05:58 -0000 Received: from unknown (HELO mail-qt1-f169.google.com) (209.85.160.169) by pb1.pair.com with SMTP; 11 Aug 2019 19:05:58 -0000 Received: by mail-qt1-f169.google.com with SMTP id x4so2581780qts.5 for ; Sun, 11 Aug 2019 09:33:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=96ovXBu65Z3uw8qw42UqSLyKcR9yFYd8UNRJsKkYnso=; b=paHeEb8kyHIubYKOCRKHWiVUhTSdhGLwafRT+Vk5lbxW0qQsivJyz/0B1Cs+YTR2JX Jqfv9nyoX+EQzr8o3Lgpww9itiuXpwqJv7dNkhFupQyKRqzXpDMnY+l8CbYRIs7s2CQ5 2qI8al5I6wPGvx/cbgPNvO7mZq4QNLDBqIKsnEds2Ey9uF2ideKyf1QVrDZoYKWpaZ2z bgMMqsYGcRELngbmkJ77xBIoRNPcXmxib3+hBz9w3CkvwEv78a5bKvHz4UZF+lKgQxEp ybo0nii63tRsu/eIaR8Og5aGvI8fiIhyOLuzjk1qjIn0vuGR9WoYkrJuggq4f3ED5neJ qRig== X-Gm-Message-State: APjAAAVgw8gQQNYlK5JOmeeX9aQC0ZKkyBeXFWCiZXsdd+NqZwiCMxW6 hkUbHdyiMq/pqXycleAwJelRs5vQP4JtxqgLFoFxDQ== X-Google-Smtp-Source: APXvYqyFlBhLO7oPrgTv+JQ0UZ1XuhL9jzTwfQRQBZZEi5c6lFbZpqY3lDXoBygzqZ3gVFZMUTY/G82TH7YByg5qWWQ= X-Received: by 2002:ac8:2498:: with SMTP id s24mr18107919qts.375.1565541233966; Sun, 11 Aug 2019 09:33:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Sun, 11 Aug 2019 11:33:42 -0500 Message-ID: To: Nikita Popov Cc: PHP internals Content-Type: multipart/alternative; boundary="00000000000021d270058fd9f97b" Subject: Re: [PHP-DEV] Adding return types to internal methods (PHP 8) From: pollita@php.net (Sara Golemon) --00000000000021d270058fd9f97b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Aug 11, 2019 at 8:24 AM Nikita Popov wrote: > After thinking about this a bit, this is going to be pretty hard to > implement. Currently return type checks are performed using a separate > opcode, which means that we need to know the return type at compile-time. > At the point where inheritance happens and we know the parent return type= , > we are no longer able to modify the opcodes of the function. We'd have to > integrate the return type check into the main return logic, with a possib= le > negative impact on performance... > > Well, we certainly can't do it without some perf impact. 100% agree there. The na=C3=AFve and simple solution is expensive enough that I'd agr= ee it's not worth doing. I can see a path to get fairly close to zero, but at the cost of a non-trivial amount of complexity. Hrmmm Yeah, ultimately I'm not sure that gives us enough to justify the cost. Okay, forget that tack pending someone being able to come up with an implementation that doesn't suck. -Sara On Sun, Aug 11, 2019 at 8:24 AM Nikita Popov wrote: > On Sun, Aug 11, 2019 at 3:01 PM Sara Golemon wrote: > >> On Sun, Aug 11, 2019 at 7:51 AM Nikita Popov >> wrote: >> >>> On Sun, Aug 11, 2019 at 2:37 PM Sara Golemon wrote: >>> > P.S. - Perhaps a way to the middle might be to introduce implicit >>> return >>> > type hints. If a child method is implemented with no return type >>> specified >>> > on a parent method which has one, then the parent's type is assumed a= t >>> bind >>> > time, then we provide a better runtime error if that assumption is >>> violated >>> > in a strict_types=3D1 context which is the only place where strict >>> covariance >>> > of return types matters to PHP. >>> > >>> >>> This is an interesting idea. There's still a BC break here, but it's mo= re >>> limited and only applies to code that is actively violating type >>> contracts >>> (that were previously implicit). Imho this should not be bound to >>> strict_types though: strict_types controls coercion behavior of scalar >>> type >>> annotations, and nothing else. It should not be overloaded with this >>> additional meaning (and I don't think the BC break is nowhere near larg= e >>> enough to justify this overloading). >>> >>> Fair. Just trying to tread as light as possible, but there is a >> vanishing point. >> >> >>> Do you have this in mind as something for use by internal classes only, >>> or >>> as a general language feature? I can see the use as a general language >>> feature (see for example the debacle where PHPUnit added "void" >>> annotations >>> to some methods). The migration problem of adding return types is >>> certainly >>> not limited to internal classes. On the other hand it does seem somewha= t >>> weird that an (inherited) return type will be enforced that was not >>> explicitly given in the source. >>> >>> I agree that it would be as useful to userspace classes as internal >> ones. It would allow library authors to embrace strong typing without >> breaking consumers who are already conforming to docblock types. >> >> It's probably worth proof-of-concepting this and making an RFC >> irrespective of the push to annotate all the things. If feasible and >> accepted, I'd be much more on board with including return types for >> internal methods in that plan however. >> > > After thinking about this a bit, this is going to be pretty hard to > implement. Currently return type checks are performed using a separate > opcode, which means that we need to know the return type at compile-time. > At the point where inheritance happens and we know the parent return type= , > we are no longer able to modify the opcodes of the function. We'd have to > integrate the return type check into the main return logic, with a possib= le > negative impact on performance... > > Nikita > > --00000000000021d270058fd9f97b--