Re: [RFC] Disallow multiple default blocks in a single switch statement

Lester Caine wrote (on 06/08/2014):

On 06/08/14 11:16, Rowan Collins wrote:

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.

It is perhaps interesting that this problem has not turned up before? As I indicated in another thread I was surprised to see 'default' as the first item in an example. I'm sure I'm not alone in always putting it at the end, and I quite often will have a previous block which does not have a 'break' so that the default element is added to other actions on some keys for that reason. How much of the core PHP is still 'normal practice' rather than 'by design' :)

You could equally have the default case run some extra logic *before* one of the steps, since it doesn't have to be last. The goto-like behaviour of case and default labels originates in C, which makes this answer on SO worth mentioning: http://stackoverflow.com/a/3110478/157957 The reason some languages require default to be the last label is presumably that they treat it as equivalent to a case statement that always matches, and so never test lower labels. "Normal practice" is often stricter than what is technically possible in a language, because it is aimed at writing readable and maintainable code. Which in turn has no bearing on the ability to specify multiple defaults (which never makes sense, except as a result of a lazy code generator). -- Rowan Collins [IMSoP]