Zeev, > > > Two more things regarding the competing RFC – it’s still alive, and > > > being promoted for PHP 7.0; And while it doesn’t create a huge BC > > > break, it allows developers to selectively create localized BC breaks, > > > on a per file basis. > > > > No, it does not. A BC break is something where existing code works, and > > you > > do nothing more than upgrade and have the new code not work anymore. > > > > With the other dual-mode RFC, if a user opts-in (enables strict mode), if > > code > > doesn't work that's not a BC break. That's a case of "you told us explicit > > you > > don't want this code to work if it's invalid, and guess what, it's > > invalid". > > That's splitting hairs IMHO. The bottom line is that many people will > undergo the same process Rasmus did as he experimented, flipping the switch > on because it's a best practice, and start having to fix their code to work. > But we can also agree on what we always agree here too :)
Saying that turning on an optional and previously unavailable option inside code causing code breaks is any way a " BC" break is pure FUD. It is not BC by any definition that we have ever used on on this list, nor is it BC based on semver nor any other community accepted definition. Let's please avoid FUD and continue to discuss the proposals at hand... Anthony
