On 14 Jul 2014, at 16:58, Andrea Faulds <a...@ajf.me> wrote: > One of the issues with the RFC as it stands is how to handle bool casting. > While int, float and string only allow lossless casting (with the exception > of objects, but we can’t really do anything about that), bool’s behaviour at > the moment is quite different. I don’t think it makes sense so I won’t > discuss the current behaviour, only possible new ones. > > One option is simply to forget about being lossless and make the bool type > hint accept any value, meaning any truthy value or any falsey value would > yield what is expected without error. This would ensure that if some stupid > programmer (like myself ;) has passed in a non-boolean truthy/falsey value to > your function, it’ll be handled correctly. It would mean all your bit hacks > ($foo & FLAG etc.) would work, anything you got from $_GET (e.g. ?foobar=1). > However, this is unlikely to catch bugs in code, because literally any PHP > value would work. For that reason, I’m not sure this is the way forward.
I don’t think that "scalar casts” should do any additional error-catching. they
target a very different usecase.
It shouldn’t guarantee correctness of the whole program. It should guarantee
that variable types are fixed inside of function.
In my opinion, this patch should act 100% similar to zpp.
And if, at some later point zpp-behaviour changes similar change should happen
to userland "scalar casts"
Some people talk about inconsistency, which is introduced by reusing same
syntax for "strict parameter types" and "scalar parameter casts”. There’s some
truth there.
Let’s use different syntax.
This might work:
function foo((int) $a)
{
var_dump($a);
}
I would read it as declaration-level casting
--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc
signature.asc
Description: Message signed with OpenPGP using GPGMail
