Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83064 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 17715 invoked from network); 18 Feb 2015 13:30:30 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Feb 2015 13:30:30 -0000 Authentication-Results: pb1.pair.com header.from=francois@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=francois@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender) X-PHP-List-Original-Sender: francois@php.net X-Host-Fingerprint: 212.27.42.2 smtp2-g21.free.fr Received: from [212.27.42.2] ([212.27.42.2:15584] helo=smtp2-g21.free.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C4/61-18888-4F394E45 for ; Wed, 18 Feb 2015 08:30:29 -0500 Received: from moorea (unknown [82.240.16.115]) by smtp2-g21.free.fr (Postfix) with ESMTP id 7C50C4B024F; Wed, 18 Feb 2015 14:30:05 +0100 (CET) Reply-To: To: "'Robert Stoll'" , "'Zeev Suraski'" , "'Nikita Popov'" , "'Rasmus Lerdorf'" Cc: "'Sara Golemon'" , "'PHP internals'" References: <54E3E27B.2010903@lerdorf.com> <2f99c47df51fa6c73131032ec50fade0@mail.gmail.com> <005201d04b6c$1122d130$33687390$@tutteli.ch> In-Reply-To: <005201d04b6c$1122d130$33687390$@tutteli.ch> Date: Wed, 18 Feb 2015 14:30:22 +0100 Message-ID: <030f01d04b7f$0c71d1a0$255574e0$@php.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKz6wpj8b81mnwJq1LfxWbU4ZJyQgGjcksIAbrU1N8Bn0wufQGLyLi6ApOAQNia5jsj4A== Content-Language: fr X-Antivirus: avast! (VPS 150217-2, 17/02/2015), Outbound message X-Antivirus-Status: Clean Subject: RE: [PHP-DEV] Scalar Type Hints v0.4 From: francois@php.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=) > De : Robert Stoll [mailto:php@tutteli.ch] > > Strict mode is useful in the sense that it prevents unnecessary = implicit > conversions (which are costly) and it improves readability. > Following an example: >=20 > function foo(string $x, int $y){ > bar(1); > return strstr($x,"hello", $y); > } >=20 > function bar(float $a){} >=20 > After adding the implicit conversions the code would look as follows: >=20 > function foo(string $x, int $y){ > bar((float) 1); > return strstr($x, "hello", (bool) $y); > } >=20 > function bar(float $a){} >=20 > In strict mode the original code would not be valid (rightly so IMO). Actually, your example is partially invalid because strict-typing = radicals now propose to add a (int -> float) exception to so-called = strict mode (which proves the approach is flawed, IMHO). You don't propose a strict-mode alternative in your example. OK, it = generates conversions and should fail. Now, how would you write the same = code using strict-mode and without adding casts which would do exactly = the same, but slower. If you just mean there's an undetected bug, you're right, but, IMO, a = C-like syntax like PHP's cannot disable (int -> bool) implicit = conversion. A partial solution can be brought by a set of strict types I am planning = to define in the single (not so weak) mode approach I am working on = (something like 'int!', 'float!',...). This would allow people who know = what they're doing to demand zval-type-based strict checks, arg by arg. = It can be used for performance reasons and for the rare cases where zval = type really matters (sorting, for instance). This would be available to = internal and userland functions. Regards Fran=C3=A7ois