Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76373
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.179 as permitted sender)
Message-ID: <53E2006E.6080809@gmail.com>
Date: Wed, 06 Aug 2014 11:16:14 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAESVnVr0J5qyAc-L0Yt_3Ahab5LVgtUErgoKsSPvgwe=QzppTw@mail.gmail.com> <CAH-PCH4bRSGrgicicxtNcQVUBM3gW-TBP1_3RVukw-0=TUpc3A@mail.gmail.com>
In-Reply-To: <CAH-PCH4bRSGrgicicxtNcQVUBM3gW-TBP1_3RVukw-0=TUpc3A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Disallow multiple default blocks in a single
 switch statement
From: rowan.collins@gmail.com (Rowan Collins)

Ferenc Kovacs wrote (on 06/08/2014):
> Hi,
>
> I think dropping this behavior is a good idea, but I'm confused by the
> reasoning related to the langspec.
> This rfc targets php.next (which is a safe move as this has BC break albeit
> would require some questionable code), but the langspec was agreed to be
> based on 5.6 and document how that works.
> So even if we accept this rfc, and remove the multiple default case,
> wouldn't we still need to document the current behavior in the spec (maybe
> mentioning that it will go away in php-net)?

According to the bug report, HHVM also accepts multiple default blocks, 
but uses the first rather than the last. It's probably not worth 
implementing specific code there to take the last default label just in 
order to adhere to a 5.6 spec, but is worth making it detect multiple 
labels to bring it in line with the proposed change.

So either we declare the php.net implementation to be in violation of 
the spec (which isn't completely insane - the spec shouldn't mirror 
behaviour to the point of incorporating the entire bug list); or we 
document the php.net behaviour as "correct", but accept that nobody is 
going to implement that part of the spec as written, and fix it in the 
next release of both the implementation and the spec.

Having the 5.6 spec match behaviour, and starting a 5.7 draft 
immediately for implementations to actually target might be a compromise?
-- 
Rowan Collins
[IMSoP]