Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76464
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU6FP57ZA0Y4t6b_9S+NXm_81cjqne-xhrK5j-oW2eiicA@mail.gmail.com>
References: <CAESVnVr0J5qyAc-L0Yt_3Ahab5LVgtUErgoKsSPvgwe=QzppTw@mail.gmail.com>
	<CAH-PCH4t1bnGwOmitU4cS4W--==8sZRhw1X-DkV0Y7zNj8E3kw@mail.gmail.com>
	<CAEZPtU6FP57ZA0Y4t6b_9S+NXm_81cjqne-xhrK5j-oW2eiicA@mail.gmail.com>
Date: Wed, 13 Aug 2014 10:48:37 +0200
Message-ID: <CAH-PCH7yt6SZv0FYWMPFGCcY2016GBG9dTQM9DxBs=gCCM8Q0A@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Sara Golemon <pollita@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2ef7ea5c0e505007edaab
Subject: Re: [PHP-DEV] [RFC] Disallow multiple default blocks in a single
 switch statement
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a11c2ef7ea5c0e505007edaab
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 13, 2014 at 10:38 AM, Pierre Joye <pierre.php@gmail.com> wrote:

> On Wed, Aug 13, 2014 at 9:47 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
> > On Wed, Aug 6, 2014 at 6:38 AM, Sara Golemon <pollita@php.net> wrote:
> >
> >> https://wiki.php.net/rfc/switch.default.multiple
> >>
> >> 'Cause this code is silly (even if it had case blocks), but we allow i=
t:
> >>
> >> switch ($expr) {
> >>   default:
> >>     notExecuted();
> >>     break;
> >>   default:
> >>     executed();
> >> }
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
> > Hi,
> >
> > sorry to jump in this late, but I'm not sure that it is a good idea to
> only
> > reject the multiple default blocks but keep the ability to have the sam=
e
> > case multiple times:
> > http://3v4l.org/eZdPU
> > in this regard I think the current status is more consistent as it woul=
d
> > after merging this patch.
> > and I also think that this isn't an important enough issue to warrant a
> BC
> > break (albeit this is the better kind of BC: probably doesn't effect to=
o
> > many people, and they will be clearly notified about the error at compi=
le
> > time) so I voted no based on this two thing.
>
> I have a mixed feeling too about doing this change in 5.x. Without
> nitpicking, it is still a BC break. I also think that making PHP
> somehow consistent, less confusing, etc. while working on the PHP
> specs, we should really target php7 for any of these changes.
>
> As of the discussions about the discussion phase, what is one week
> more anyway? Especially in summer when the lucky ones are in holidays?
> ;)
>
>
after re-reading my email, I realized that instead of
"and I also think that this isn't an important enough issue to warrant a BC
break"
I wanted to say that
and I also think that this isn't an important enough issue to warrant a BC
break in a minor version



--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a11c2ef7ea5c0e505007edaab--