Stanislav Malyshev, >> 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
People have been using the term "strict" with clearly different meanings over the threads. For some it means total strictness, for others just between numbers vs strings, for others it means that coercion should occur only when there is no data loss and there are many other meanings. Even Nikic presented different versions of "strict" proposals on an old article > http://nikic.github.io/2012/03/06/Scalar-type-hinting-is-harder-than-you-think.html That's why I said the meaning of a "strict" implementation hasn't reach consensus but you tried pretty hard to do not understand it. Citation again: > 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 [...] You're basically stretching my words, trying to make it look mean in some way (stop that ;) Now I understand why folks rage quit internals once in a while... PS: I'm out this thread, but hope the POV about the language feature was clear enough to the objective debate. 2015-01-15 22:41 GMT-03:00 Stanislav Malyshev <smalys...@gmail.com>: > 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
