Hi! > detriment of coercive types simply because there is no general > consensus about what "strict" means :)
I don't see any place for "consensus" and "non-consensus" here - unless you want to redefine words to have arbitrary meanings so nobody understands you, it is pretty clear what "strict" means - typing system in which the variable marked with certain type accepts only value of that type and nothing else. What other definition could you have in mind? > But I also don't want to have coercive type hints to occupy the best > "syntax slot" that could be used for more strict type checks That's fine that you want your use case to be most convenient for you, unfortunately that place has been already taken for years. > debate. I'm just claiming that `(int) $num` is more explicit, has no > BC breaks and should, IMMO, be the preferred choice. No, it should not be, and I just wrote two mails explaining why exactly it should not. Here's the third. > Sorry, but this is the syntax used by the manual to describe functions > usage, not the actual implementation. The manual can be updated. The Of course, we can rewrite the whole manual and the whole language. The question is - why we should make such huge changes if we already have this meaning and it has been there for years and it always meant exactly that - coercive typing for scalars - and never meant anything else? > implementation itself can't be changed after major version release. The manual is what people read and rely on. But there's a bigger issue that you keep ignoring - that the functions having scalar typed argument *are* coercive *right now*. You describe it as if it's a typo in the manual that can be fixed or something that happened by accident and nobody intended it. Nothing can be further from the truth - it's how weak typing has been always working in PHP. You want new feature for your use case? Fine, but claiming existing syntax for it and saying "no problem we'd just rewrite the whole manual and disregard 20 years of PHP history" sounds like a bit too much to ask. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
