Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76374
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <53E2006E.6080809@gmail.com>
References: <CAESVnVr0J5qyAc-L0Yt_3Ahab5LVgtUErgoKsSPvgwe=QzppTw@mail.gmail.com>
	<CAH-PCH4bRSGrgicicxtNcQVUBM3gW-TBP1_3RVukw-0=TUpc3A@mail.gmail.com>
	<53E2006E.6080809@gmail.com>
Date: Wed, 6 Aug 2014 12:44:49 +0200
Message-ID: <CAEZPtU5N=tba1F2hLopwk7m2xX5=WtO8in=_ZDH=aNOQA8mZgw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Disallow multiple default blocks in a single
 switch statement
From: pierre.php@gmail.com (Pierre Joye)

On Wed, Aug 6, 2014 at 12:16 PM, Rowan Collins <rowan.collins@gmail.com> wrote:
> 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?

Too late for 5.6 but it would have been one of these acceptable BC and
sanity change. I did not even know it was possible and I do not think
anyone would be insane enough to rely on that :)

We will need a 5.7 anyway, so yes,  5.7 sounds like a reasonable target.

And I indeed like this RFC, specs work is paying off.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org