Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:76509 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 48142 invoked from network); 14 Aug 2014 09:33:43 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Aug 2014 09:33:43 -0000 Authentication-Results: pb1.pair.com smtp.mail=addw@phcomp.co.uk; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=addw@phcomp.co.uk; sender-id=permerror Received-SPF: pass (pb1.pair.com: domain phcomp.co.uk designates 78.32.209.33 as permitted sender) X-PHP-List-Original-Sender: addw@phcomp.co.uk X-Host-Fingerprint: 78.32.209.33 freshmint.phcomp.co.uk Received: from [78.32.209.33] ([78.32.209.33:60750] helo=mint.phcomp.co.uk) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 22/21-40673-6728CE35 for ; Thu, 14 Aug 2014 05:33:43 -0400 Received: from addw by mint.phcomp.co.uk with local (Exim 4.72) (envelope-from ) id 1XHrPe-0004FU-Q0 for internals@lists.php.net; Thu, 14 Aug 2014 10:33:38 +0100 Date: Thu, 14 Aug 2014 10:33:38 +0100 To: internals@lists.php.net Message-ID: <20140814093338.GY11050@phcomp.co.uk> Mail-Followup-To: internals@lists.php.net References: <3F1B2834-3939-4F86-86E0-207D2CE469D6@ajf.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Parliament Hill Computers Ltd User-Agent: Mutt/1.5.20 (2009-12-10) Subject: Re: [PHP-DEV] [RFC] Introduce Abstract Syntax Tree From: addw@phcomp.co.uk (Alain Williams) On Thu, Aug 14, 2014 at 10:25:11AM +0100, Chris Wright wrote: > > My personal opinion is that things like $a[$i++] = $i++ have zero practical > > relevance (and also think that anyone using something like this deserves > > any breakage he gets). I'd rather save some lines of code than maintain any > > behavior guarantees for that. But some people have contrary opinions on > > this, so I'm bringing up the point for discussion. > > +1. It's documented as undefined behaviour, doing it in the first > place is highly non-obvious to the reader with a clear ambiguity, it's > fine by me to break from the current behaviour. +1 It is OK to define some things as undefined and have them break between releases - even minor releases. I always teach it as undefined - as it is in most programming languages. Likewise, if the next 2 characters on input are 'a' then 'b' what gets assigned could either be 'ab' or 'ba': $TwoChars = fgetc($in) . fgetc($in); Some code is just broken. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include