Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:75530 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 43253 invoked from network); 15 Jul 2014 10:59:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Jul 2014 10:59:59 -0000 Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender) X-PHP-List-Original-Sender: derick@php.net X-Host-Fingerprint: 82.113.146.227 xdebug.org Linux 2.6 Received: from [82.113.146.227] ([82.113.146.227:40991] helo=xdebug.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 92/F8-15121-EA905C35 for ; Tue, 15 Jul 2014 06:59:58 -0400 Received: from localhost (localhost [IPv6:::1]) by xdebug.org (Postfix) with ESMTPS id 3741810C032; Tue, 15 Jul 2014 11:59:55 +0100 (BST) Date: Tue, 15 Jul 2014 11:59:55 +0100 (BST) X-X-Sender: derick@whisky.home.derickrethans.nl To: Rowan Collins cc: internals@lists.php.net In-Reply-To: <53C3F70A.7010706@gmail.com> Message-ID: References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <53C3F70A.7010706@gmail.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening) From: derick@php.net (Derick Rethans) On Mon, 14 Jul 2014, Rowan Collins wrote: > Derick Rethans wrote (on 14/07/2014): > > A compromise by adding more inconsistencies. > > The only way of not introducing some inconsistencies (or, to put it another > way, new features) is to use strict type hints, which perform no casting, and > error on invalid input, since that's what the existing type hints do, in > particular "array". There's broad consensus that that wouldn't be very > "PHP-ish", and it has been rejected in previous discussions. I am quite aware of that. > Here are the main variants discussed in this thread: > > 1) add type hints using existing syntax, but which are actually silent casts, > rather than the strict validation performed for existing types > 2) add type hints using existing syntax, which are casts, but also act > differently from existing casts by emitting some kind of notice > 3) add cast hints using a new syntax > 4) add type hints using existing syntax, which use a new "lossless cast", i.e. > perform validation for completely wrong input ('abc' as an int param) but > allow juggling for "reasonable" input ('123' as an int param). > > Option 2 (or 3) could also be implemented by making *all* lossy casts emit > some kind of notice. > > This RFC currently proposes option 4. Yes. And with that option I have a problem, as nothing else does it like that now - hence my arguing against "a new set of casting rules". Option 1 is equivalent to my argument that this should be equivalent: function foo(int $var) {} function foo($var) { $var = (int) $var; } and called by f.e.: foo('123abc'); cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine