Hi Claude, The very risk is that the programmer must be aware that the return > convention has changed. Recall that not everyone run static analysers, > especially for such a trivial migration, and that not every code is > statically analysable (e.g.. `$foo->$bar()`). >
I hope that I don't sound elitist, but codebases not using static analysis... are kind of hopeless... That is, in my opinion, there's no other option to run a larger PHP project successfully than to either use static analysis or to have programmers who don't commit any mistakes. For the rest of the less valuable projects, the cost of messing up with the return value check is not much. What is the purpose of changing the return convention of IntlCalendar > methods, and is it worth? > The purpose is to have the "correct" return type. Is it worth it? Well, it depends... For me, what's important is that PHP becomes a more and more predictable and accessible language, and I care less about minimizing backward compatibility breaks. The introduction of the "true" type was useful, since we now have more correct type information, but adding new functions with this return type would be unfortunate, as many people (especially the ones coming from other languages) would be puzzled about the meaning of the "true" type more than if the return type was "void". I'm pretty sure that George - the author of the true type - agrees that the main purpose of this type is to eliminate its declarations from internal functions and methods. Regards, Máté
