Re: [Proposal] Modification to ?: functionality

On Tue, Nov 26, 2013 at 5:54 PM, Etienne Kneuss <colder@php.net> wrote: > > > > On Tue, Nov 26, 2013 at 6:48 PM, Chris London <me@chrislondon.co> wrote: > >> On Tue, Nov 26, 2013 at 10:41 AM, Paul Dragoonis <dragoonis@gmail.com >> >wrote: >> >> > >> > >> > >> > On Tue, Nov 26, 2013 at 4:58 PM, Chris London <me@chrislondon.co> >> wrote: >> > >> >> On Tue, Nov 26, 2013 at 8:15 AM, Mats Lindh <mats.lindh@gmail.com> >> wrote: >> >> >> >> > On Tue, Nov 26, 2013 at 3:43 PM, Chris London <me@chrislondon.co> >> >> 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. >> > > I don't see any value in adding yet another operator for this, we already > support this through: > > $foo = @$arr['value'] ?: ""; > Constant intentional error suppression isn't really what we need since the error still happens it just doesn't go through logging and such, whereas from my limited understanding isset() will not trigger any errors to happen at all, so there is a difference here for sure. > > >> >> >> > >> > 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 >> >> > >> >> >> > >> > >> > > > > -- > Etienne Kneuss > http://www.colder.ch >