On Sun, Jan 25, 2015 at 5:02 AM, Andrea Faulds <a...@ajf.me> wrote: > Hi everyone, > > Just a few small updates. > > I’ve made a small change to this RFC. Instead of the strict mode syntax being > declare(strict_typehints=TRUE), it’s now declare(strict_types=1) instead. > This makes it a bit quicker to type - important given you’d need to type it a > lot - without sacrificing much readability. It also avoids using the words > “type hint”, which I understand are contentious to some people. > > The patch now includes a more extensive set of tests: > https://github.com/TazeTSchnitzel/php-src/tree/scalar_type_hints_2_strict_mode/Zend/tests/typehints/ > > The pull request is also now green on Travis (aside from two failures on the > debug build - but they also fail in master). > > Levi’s Return Types RFC has now passed, so now the RFC needs to cover that. > The RFC currently doesn’t discuss return types, save for a paragraph in the > Future Scope section. When the return types patch is merged, I’ll update the > scalars patch, and then update the RFC. A point of contention here is whether > or not return types should always be strict, or whether they should also obey > the strict/weak modes. I’m not entirely sure on that one, that specific item > may end up going to a vote. That said, I do lean towards always strict, given > you can usually ensure your return type’s correct. > > Thanks. > > -- > Andrea Faulds > http://ajf.me/ >
Hello, personally I still don't like this RFC in it's current form and "shorter" declare won't change it. I was thinking a lot about the typehints in PHP for last few days and I think having only one way would be the best - and it's somewhere between the curent weak and strict typing. My main "issue" is that the current weak typing is too loose and the strict typing is too strict. The problem with the current strict typing is that you cannot pass "int" to a "float" parameter, even though there can be a totally lossless conversion and it works in other strongly typed languages. And being able to pass a float(1.5) to int and lose the 0.5 value doesn't make sense as well, because data will get lost. Neither of those feels somehow "predictable" and "natural". Also, after a little bit of thinking, if someone needs to do a type conversion while calling a method, writing foo((int) $bar) isn't that hard. So, I think it would be best to choose just one of these two approaches and either loosen it a little or make it more strict (so data loss doesn't happen). But I guess this approach would be inconsistent with how the built-in PHP functions work? PS: Ideally, the data loss rules should be made for types and not values (like the old scalar type hints RFC had), so you don't get unpredictable results. The only ones I can think of right now are basically int -> bool, int -> float, object (w/ __toString) -> string, int -> string, float -> string? Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
