# [RFC] Scalar Type Hinting With Casts (re-opening) - Thread: https://externals.io/message/75510 - Original archive: https://news-web.php.net/php.internals/75510 - Started by Chuck Reeves on 2014-07-14T20:23:56+00:00 - Messages: 5 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #75510 — Chuck Reeves — 2014-07-14T20:23:56+00:00 URL: https://externals.io/message/75510#75510 I am new to the list and internals so my question might be obvious to others: Why even cast the variable? When I look at a function and see: function myFunc(array $someData) { //some processing } I understand that myFunc requires an array passed in. If I try to call myFunc like so: myFunc('foobar'); I get a fatal error stating that I did not pass in an array. If I try with stdClass: myFunc(new \stdClass()); I will get the same error however If I cast the object before passing in like so: myFunc((array) new \stdClass()); It works just fine. The benefit of having the hint tells whom ever is going to consume the function that the parameter needs to be casted to the scalar type. If I have this: function addTwoValues(int $valueOne, int $valueTwo); It is clear that i need to make sure I'm using int's. If I try to call that function with any other type, I would like to get the error instead of some kind of auto-magical cast into something that could product strange results. I think the benefit is in having the hint with excluding the cast of the value. Let the user cast the value to what the function requires. IMHO Allow the author of the function to dictate what is needed to execute. > > > > > […] > favourite from that list of features to have the privilege of dedicated > syntax in function signatures. > > That’s why this RFC is supposed to be a best-compromise solution between > strict and just casting. The hope is to appease both sides and provide the > most workable solution, really. It’s also the style that I, myself, like > best, because it’s strict enough to catch bugs (I like that), and it keeps > PHP a type-shifting language (I like that too). > > -- > Andrea Faulds > http://ajf.me/ --- ## #75511 — Park Framework — 2014-07-14T22:16:49+00:00 URL: https://externals.io/message/75510#75511 · In reply to: #75510 Maybe we should make two different syntax? fun(int $num, array $list) - for strict type compliance fun((int) $num, (array) $list) - converted to type It will be very obvious, and without magic. 2014-07-14 23:23 GMT+03:00 Chuck Reeves : > I am new to the list and internals so my question might be obvious to > others: Why even cast the variable? When I look at a function and see: > > > function myFunc(array $someData) > { > //some processing > } > > I understand that myFunc requires an array passed in. If I try to call > myFunc like so: > > myFunc('foobar'); > > I get a fatal error stating that I did not pass in an array. If I try with > stdClass: > > myFunc(new \stdClass()); > > I will get the same error however If I cast the object before passing in > like so: > > myFunc((array) new \stdClass()); > > It works just fine. The benefit of having the hint tells whom ever is > going to consume the function that the parameter needs to be casted to the > scalar type. > > If I have this: > > function addTwoValues(int $valueOne, int $valueTwo); > > It is clear that i need to make sure I'm using int's. If I try to call > that function with any other type, I would like to get the error instead of > some kind of auto-magical cast into something that could product strange > results. > > I think the benefit is in having the hint with excluding the cast of the > value. Let the user cast the value to what the function requires. IMHO > Allow the author of the function to dictate what is needed to execute. > > > > > > […] > the > > […] > keeps > > […] --- ## #75512 — Alain Williams — 2014-07-14T22:24:31+00:00 URL: https://externals.io/message/75510#75512 · In reply to: #75511 > Maybe we should make two different syntax? > > fun(int $num, array $list) - for strict type compliance > fun((int) $num, (array) $list) - converted to type +1 Don't forget to note that we will still retain the current syntax: fun($num, $list) - arguments passed as is, not type checking/juggling -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include : > > > […] > > +1 > > Don't forget to note that we will still retain the current syntax: > > fun($num, $list) - arguments passed as is, not type > checking/juggling > Yes, of course! --- ## #75549 — Philip Sturgeon — 2014-07-15T15:05:47+00:00 URL: https://externals.io/message/75510#75549 · In reply to: #75511 On Mon, Jul 14, 2014 at 11:16 PM, Park Framework wrote: > Maybe we should make two different syntax? > > fun(int $num, array $list) - for strict type compliance > fun((int) $num, (array) $list) - converted to type > > It will be very obvious, and without magic. > > > 2014-07-14 23:23 GMT+03:00 Chuck Reeves : > > > […] A massive +1 for this approach. I had the same thought the other day after watching this thread aganoise between "to cast, or not to cast." Trying to make some types automatically cast and some just assert (like some do already) is a road that leads to pain and suffering. Trying to make them all just assert is not "the PHP way". Trying to make them all cast (thus changing the exist array assertion into a cast action) would be bizarre and strange. So what is left? Two syntaxes, so cast and assert can both be taken care of. foo(int $num) - for strict type compliance This HAS to be an int and an array. Nothing else will fly. bar((int) $num) - converted to type This has to be anything that could be turned into an int, which to be fair is basically anything, and anything that can be turned into an array. foo(123); // OK foo("123"); // Not OK foo("123a"); // Really not OK bar(123); // OK bar("123"); // Casts to 123 bar("123a"); // Casts to 123 bar(" 123a"); // Casts to 123 Even if you guys would like to suggest that foo("123"); should be ok because $_GET variables, I would sill strongly urge people to consider the "type assertions dont cast" approach, and add easy casting for "assert and cast" functionality. It's the most consistent and easy to explain approach, even if it does lead to the occasional developer saying "Oh, my unfiltered $_GET input is a string instead of an int. How do I... ahh I just use foo((int) $_GET['whatever']); Not an issue in 2014 I believe.