Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:70416 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 73059 invoked from network); 26 Nov 2013 17:49:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Nov 2013 17:49:00 -0000 Authentication-Results: pb1.pair.com header.from=me@chrislondon.co; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=me@chrislondon.co; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain chrislondon.co does not designate 74.125.82.172 as permitted sender) X-PHP-List-Original-Sender: me@chrislondon.co X-Host-Fingerprint: 74.125.82.172 mail-we0-f172.google.com Received: from [74.125.82.172] ([74.125.82.172:57689] helo=mail-we0-f172.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 14/E6-39355-B0FD4925 for ; Tue, 26 Nov 2013 12:49:00 -0500 Received: by mail-we0-f172.google.com with SMTP id w62so10086wes.3 for ; Tue, 26 Nov 2013 09:48:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yXXPUAUJk1QDPmlsFVPk51Dr9jIT9EqLFhCVg4g2lU8=; b=IASn0xo1ARXbDo3c4feIGpW4rZ+6by07aG+HBEfy4E0Ad1muIyXqzbQc6w/Y8Edbj5 eWCJrTQvjHZLHKHgVrwNN5LqTXmIw3RVGWLd89csDQxMO4DZ624rntXLwsez2+xsn+4p SKLq0TROkrQAAiqiu0dRg2hB+S4PQeo22tF+HWXjpq1RiNd1tCJ/fphE1z5wTZdHzuOx IpTvotOrAvZAJ1S3HyRu3wFzY1sV6s3yuoKNroybEXWF50VD0NDwzF34TnnryBKT7bq7 jK5x9ce6FVJN4Mp/u4OSYL7H7h/jbbeMHXj3nqXXbVi9izXq/lhAWSN/k5wgMgIFasZb LdHg== X-Gm-Message-State: ALoCoQlzsgeHddiBmnwAZCvShTz2FC5uxEy1NFMQtXTEOqcbs29IZuEAUB6jIH4XaodtDObNTopV MIME-Version: 1.0 X-Received: by 10.180.75.235 with SMTP id f11mr19150471wiw.27.1385488136918; Tue, 26 Nov 2013 09:48:56 -0800 (PST) Received: by 10.217.153.135 with HTTP; Tue, 26 Nov 2013 09:48:56 -0800 (PST) X-Originating-IP: [66.219.207.210] In-Reply-To: References: Date: Tue, 26 Nov 2013 10:48:56 -0700 Message-ID: To: Paul Dragoonis Cc: Mats Lindh , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=f46d043c81ba3dee6c04ec18189b Subject: Re: [PHP-DEV] [Proposal] Modification to ?: functionality From: me@chrislondon.co (Chris London) --f46d043c81ba3dee6c04ec18189b Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 26, 2013 at 10:41 AM, Paul Dragoonis wrote: > > > > On Tue, Nov 26, 2013 at 4:58 PM, Chris London wrote: > >> On Tue, Nov 26, 2013 at 8:15 AM, Mats Lindh wrote: >> >> > On Tue, Nov 26, 2013 at 3:43 PM, Chris London >> wrote: >> > >> >> I believe these two statements are functionally equivalent: >> >> >> >> $foo = $foo ? $foo : 'default'; >> >> >> >> $foo = $foo ?: 'default'; >> >> >> > >> > They are. >> > >> > >> > I would like to change it so it also checks for isset() so I propose the >> >> following would be functionally equivalent: >> >> >> >> $foo = isset($foo) && $foo ? $foo : 'default'; >> >> >> >> $foo = $foo ?: 'default'; >> >> >> > > We can't change the behaviour of ?: that ship has already sailed, we'll > just be hurting existing codebases on upgrading and more user education is > required to understand non-visual changes in syntax like this, lets try to > learn from our mistakes by not changing 'behaviour' anymore. > > An alternative syntax that is similar and not ugly would be good since the > ?: behaviour was broken from the start since you still need to run isset() > before running ?: which was the problem we tried to solve in the first > place but it just didn't happen. > > I don't like the @ symbol it's too different from what's already there on > the ternary logic. > My reason for the @ symbol was that it's already used to suppress errors so to me it seems like it could be interpreted as a suppressed ternary but I'm open to other suggestions. > > Proposal: $foo = $arr['value'] ?:: ""; > I'd be fine with this choice. > > Thoughts? > > > >> > The would break the assumption that a reference to an uninitialized >> value >> > would generate a notice, unless explicitly handled in the logic. >> > >> > While I also would like to have something similar to ?: to handle >> default >> > values for array keys, etc., this would change a fundamental assumption >> > that as been in place for many years now. I'm not sure if that's a BC >> break >> > that would be acceptable this late. An alternative operator may be more >> > suitable. >> > >> >> What do you think about using: >> >> $foo = $foo @: 'default'; >> >> and possibly >> >> $foo @= 'default'; >> >> >> >> > >> > The change proposed has also been discussed several times since the >> > implementation of ?:. See the ifsetor-RFC: >> > >> > https://wiki.php.net/rfc/ifsetor >> > >> > It also contains links to the discussion around the feature back then. >> > >> > --mats >> > >> > > --f46d043c81ba3dee6c04ec18189b--