Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83317 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 38061 invoked from network); 20 Feb 2015 16:08:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Feb 2015 16:08:08 -0000 Authentication-Results: pb1.pair.com smtp.mail=ircmaxell@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ircmaxell@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.52 as permitted sender) X-PHP-List-Original-Sender: ircmaxell@gmail.com X-Host-Fingerprint: 209.85.215.52 mail-la0-f52.google.com Received: from [209.85.215.52] ([209.85.215.52:35460] helo=mail-la0-f52.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5D/B3-14173-7EB57E45 for ; Fri, 20 Feb 2015 11:08:08 -0500 Received: by labgm9 with SMTP id gm9so7126770lab.2 for ; Fri, 20 Feb 2015 08:08:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ccajm9uw673cFfo5GxZSKdU9HljS9i0kbbCNsf4v1k8=; b=k86d0e+YD+TUO7Wz352oXjVFe/yJpzgvCtE/TZ9qDhSTyaZP9gLNcSXevmK5TItDuU hHeBA9Wfk1wjobfLPMs5lLbQYAcTHIXcnHjiZrDbTnikigZwxZeXbE0obDF+yu2Ydrf4 NOVdYoilvZRW5N+BHxAb/44/y0tBGOcLunwXgIBM0BHUc0L7U8/j9mAtwh2gLYPgXr5I mA1CkoDKdgVsPzEbjDKQPHAp389pWj7Wbqj5s3uQ/3jTu6f9d6bCh10gdQnywOrD0E3w 0JRJcfpR4ibU+VnpgGcrrm2rpM5OXFbG5w83QNN08jm3dKXTWqLQcJqQS/P2jD5AE0lI vSnA== MIME-Version: 1.0 X-Received: by 10.153.5.11 with SMTP id ci11mr8672719lad.95.1424448484256; Fri, 20 Feb 2015 08:08:04 -0800 (PST) Received: by 10.25.43.9 with HTTP; Fri, 20 Feb 2015 08:08:03 -0800 (PST) In-Reply-To: References: <011801d04a07$83ab1c00$8b015400$@php.net> <016f01d04a3a$e9183220$bb489660$@php.net> <022801d04ab1$4a0c47d0$de24d770$@php.net> <1913e09d7f52541901d8574d2080a63f@mail.gmail.com> <7a5d96b34b98ec1f3ee17be7fa6a1e81@mail.gmail.com> <2CBDEB67-3DE3-437D-9AF3-0E6A92027244@zend.com> <4cc0c81c7199a452534bb8edcdb19914@mail.gmail.com> <54E589F6.9030002@garfieldtech.com> <54E66569.8000709@garfieldtech.com> Date: Fri, 20 Feb 2015 11:08:03 -0500 Message-ID: To: Zeev Suraski Cc: Dmitry Stogov , Pierre Joye , Larry Garfield , "internals@lists.php.net" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Reviving scalar type hints From: ircmaxell@gmail.com (Anthony Ferrara) Zeev, On Fri, Feb 20, 2015 at 10:24 AM, Zeev Suraski wrote: > >> On 20 =D7=91=D7=A4=D7=91=D7=A8=D7=B3 2015, at 16:55, Anthony Ferrara wrote: >> >> verification and static analysis aren't enough? >> > > Anthony, > > While IMHO they're not enough to warrant substantial deviation from PHP's= behavior, this is a subjective question that others might answer different= ly. > > But there's also an objective issue. There's a serious question mark whe= ther the type of hint - strict, coercive of otherwise can have any sort of = implications on one's ability to conduct static analysis, JIT or AOT (I'm b= ringing those up again since they're closely related in terms of what you c= an or cannot infer). > > Now, I'll contend that even though I don't think we are, perhaps we're mi= ssing something. But at the very least it should be clear to the list ther= e's serious doubt on whether there's any extra value there even if they do = seem static analysis critical. If there is, it's likely to be very, very l= imited in scope. Let's simply agree to disagree here :-) >> That's not saying you should want to use statically typed for >> everything. And nor would I support PHP moving to pure statically >> typed (which is why the proposal I'm backing doesn't). > > We're on the same page here. But the kinds of static analysis benefits y= ou seem to believe we can get from strict type hints would require that - s= trong typing, variable declarations, perhaps changes to casting rules - not= just around that narrow interface between callers and callees. Thankfully= that's not on the table. That's also not necessary in most cases. You can infer a lot about the types of variables just having arguments declared. In most cases, you can infer enough for static analysis to work. In the cases you can't, that's actually a valid result of the analysis because you may have undefined behavior. Example: function foo(string $a): int { return $a + 1; } You can't infer the type of $a+1 because the conversion of $a->numeric that happens is unstable from a type perspective. But PHP's type changes are predictable enough where the majority of sane cases are predictable. Both Swift and Go behave like this. Where you only *need* explicit declarations on the arguments, the rest can be inferred. And where it can't infer, it raises a type error. Anthony