On Wed, Aug 13, 2014 at 11:42 AM, Andrea Faulds <a...@ajf.me> wrote: > Hi! > > On 13 Aug 2014, at 08:47, Ferenc Kovacs <tyr...@gmail.com> wrote: > > > 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 too > > many people, and they will be clearly notified about the error at compile > > time) so I voted no based on this two thing. > > This isn’t really a BC break. Multiple default blocks didn’t actually work > anyway, we just silently ignored extra ones. >
not sure what do you mean here, multiple default cases can be reached the same way as any other duplicated case branch(as shown in my snippet in the mail you replied to). even if those were always "silently ignored" as you falsely claim, it would still be a BC break, as code working before this change would stop working with a fatal error. > > On 13 Aug 2014, at 09:13, James <ja...@notjam.es> wrote: > > > I entirely believe this behavior is weird and should be removed. However, > > breaking backwards > > compatibility in a minor release because the incomplete spec says so is > > kind of odd. A BC break > > is a BC break, which doesn't belong in a minor revision. > > It isn’t a BC break that will affect anyone. It fixes a parser bug. > it is a BC break, but I tend to agree that there isn't much code intentionally using this behavior (but I'm also think that nobody really looked for examples and just guessing about the usage of this feature), but we had explicit phpt test for this behavior so I would call it a bad design decision or lazy coding than an actual bug or hindsight. > > > This has been known to at least one person for many years if 034.phpt is > to > > be believed. > > Just because it’s tested doesn’t mean anyone relies on it. We have plenty > of tests which ensure PHP contains bugs and will error if they don’t. > sure, and those which we consider bugs are usually tests which expect the correct behavior and marked as XFAIL so we won't forget that they should be fixed. those which are testing and expecting the "bad" behavior is for us to not change those unintentionally, alas introduce unintentional BC breaks. > > > I could see > > where people would use it - there are reasons to, even if they are poor > in > > choice to do so. > > How, exactly, could there ever be a use for having multiple default: > sections and ignoring all but one? I think you forget the fall-through cases (eg. a case/default without a break/continue), in those cases all of the matching cases will be executed (even the duplicated ones as they are all matching) > This “feature” is completely and utterly useless, and I’ll eat my hat if > anyone intentionally relied on it. > not sure about the multiple defaults, but I'm fairly sure that there are code out there which uses switch blocks as state-machines, and changes the switch variable in the case blocks, and have duplicated case blocks for executing code after the switch variable reached it's final form. and I consider the default block as a glorified wildcard case pattern, so I don't think that it is a good idea to prevent having multiple default blocks while allowing the normal case blocks to check for the same value multiple times. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
