# Return type hinting patch - Thread: https://externals.io/message/37218 - Original archive: https://news-web.php.net/php.internals/37218 - Started by Sam Barrow on 2008-04-25T15:30:10+00:00 - Messages: 37 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/37218.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #37218 — Sam Barrow — 2008-04-25T15:30:10+00:00 URL: https://externals.io/message/37218#37218 Attached is my return type hinting patch. It allows type hinting for parameters and return values. Int, float, bool, string, num, scalar, resource, object, array, and class names are supported for both parameters and return values. Objects with __toString methods are allowed to pass for scalar and string type hints. function myTypedFunction returns int(string $stuff, bool, $things, num $amount) { return 'This will cause an error.' } I want to move the returns clause after the parameter list, but I couldn't get it to work in the parser: function x($param) returns y { return new y } Parameters and return values are strict. Int means int (to the type), etc. For type hinted parameters, null is allowed only if it is the default value. Implementations of abstract functions must be compatible both in their parameter and return types. Mismatched types will cause an error. Note: The parameter type hinting is complete. The return type hinting works, but there is a small memory leak which I do not know how to fix. Besides that it's running perfectly, it's very minor obstacle, I'm just not familiar enough with C to fix this right now. --- ## #37223 — Stanislav Malyshev — 2008-04-25T17:06:18+00:00 URL: https://externals.io/message/37218#37223 · In reply to: #37218 Hi! In general, it'd be very nice to have some definition of the proposed feature beyond the patch. It would probably answer some of my questions that follow :) > parameters and return values. Objects with __toString methods are > allowed to pass for scalar and string type hints. What about objects that can be converted to other types (cast_object handler)? > function myTypedFunction returns int(string $stuff, bool, $things, num > $amount) { > return 'This will cause an error.' > } What about return "1"? Also I notice it introduces new keyword - returns. Is it necessary? Each new keyword means broken code. > Parameters and return values are strict. Int means int (to the type), Meaning that int would reject 1.0, true and "1"? bool would reject 1 and 0 and null? Ouch, ouch, ouch. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #37224 — Sam Barrow — 2008-04-25T17:55:12+00:00 URL: https://externals.io/message/37218#37224 · In reply to: #37223 > Hi! > > In general, it'd be very nice to have some definition of the proposed > feature beyond the patch. It would probably answer some of my questions > that follow :) > > > […] > > What about objects that can be converted to other types (cast_object > handler)? Hadn't thought about these, don't see why it couldn't be added though. > > […] > > What about return "1"? Also I notice it introduces new keyword - > returns. Is it necessary? Each new keyword means broken code. We could probably find a way to use the return keyword or another syntax, I just did it like this for simplicity. > > […] > > Meaning that int would reject 1.0, true and "1"? bool would reject 1 and > 0 and null? Ouch, ouch, ouch. As it is now, yes, this works just like parameter hints. Could be changed if decided upon. --- ## #37225 — Sam Barrow — 2008-04-25T18:16:02+00:00 URL: https://externals.io/message/37218#37225 · In reply to: #37218 Can anyone help me with this? Here is the current function declaration rule: `T_FUNCTION` { $1.u.opline_num = CG(zend_lineno); } is_reference `T_STRING` optional_function_return_type { zend_do_begin_function_declaration(&$1, &$4, 0, $3.op_type, NULL, &$5 TSRMLS_CC); } '(' parameter_list ')' '{' inner_statement_list '}' { zend_do_end_function_declaration(&$1 TSRMLS_CC); } I want to move "optional_function_return_type" AFTER the parameter list, but I also need to pass it to zend_do_begin_function_declaration. Is this even possible? What I'm trying to acheive is this: function a($arg1, $arg2) return int { } Currently: function a return int($arg1, $arg2) { } > Attached is my return type hinting patch. It allows type hinting for > parameters and return values. Int, float, bool, string, num, scalar, > resource, object, array, and class names are supported for both > parameters and return values. Objects with __toString methods are > allowed to pass for scalar and string type hints. > > function myTypedFunction returns int(string $stuff, bool, $things, num > $amount) { > return 'This will cause an error.' > } > > I want to move the returns clause after the parameter list, but I > couldn't get it to work in the parser: > > function x($param) returns y { > return new y > } > > Parameters and return values are strict. Int means int (to the type), > etc. For type hinted parameters, null is allowed only if it is the > default value. > > Implementations of abstract functions must be compatible both in their > parameter and return types. Mismatched types will cause an error. > > Note: The parameter type hinting is complete. The return type hinting > works, but there is a small memory leak which I do not know how to fix. > Besides that it's running perfectly, it's very minor obstacle, I'm just > not familiar enough with C to fix this right now. --- ## #37226 — Sam Barrow — 2008-04-25T18:16:30+00:00 URL: https://externals.io/message/37218#37226 · In reply to: #37223 > I notice it introduces new keyword - > returns. Is it necessary? Each new keyword means broken code. > I have adapted the patch to reuse the "return" keyword. --- ## #37227 — Alain Williams — 2008-04-25T18:23:41+00:00 URL: https://externals.io/message/37218#37227 · In reply to: #37225 > > Can anyone help me with this? > > Here is the current function declaration rule: > `T_FUNCTION` { $1.u.opline_num = CG(zend_lineno); } is_reference `T_STRING` > optional_function_return_type { zend_do_begin_function_declaration(&$1, > &$4, 0, $3.op_type, NULL, &$5 TSRMLS_CC); } '(' parameter_list ')' '{' > inner_statement_list '}' { zend_do_end_function_declaration(&$1 > TSRMLS_CC); } > > I want to move "optional_function_return_type" AFTER the parameter list, > but I also need to pass it to zend_do_begin_function_declaration. Is > this even possible? > > What I'm trying to acheive is this: > > function a($arg1, $arg2) return int { > } > > Currently: > > function a return int($arg1, $arg2) { > } Why note the following (which would be more C like): function return int a($arg1, $arg2) { } -- Alain Williams Linux 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 Chairman of UKUUG: http://www.ukuug.org/ #include Why note the following (which would be more C like): > > function return int a($arg1, $arg2) { > } > > It gets a little long when you're using classes abstract protected function return int dostuff() { } vs abstract protected function dostuff() return int { } --- ## #37229 — Stanislav Malyshev — 2008-04-25T18:28:00+00:00 URL: https://externals.io/message/37218#37229 · In reply to: #37227 Hi! > Why note the following (which would be more C like): > > function return int a($arg1, $arg2) { > } In C I am familiar with "return" keyword is never used in function definition. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #37230 — Sam Barrow — 2008-04-25T18:44:07+00:00 URL: https://externals.io/message/37218#37230 · In reply to: #37227 I figured it out, the syntax is now as follows: function a($b, $c) returns d { } I'll post an update soon. --- ## #37233 — Jeremy Privett — 2008-04-25T19:08:04+00:00 URL: https://externals.io/message/37218#37233 · In reply to: #37230 Sam Barrow wrote: > I figured it out, the syntax is now as follows: > > function a($b, $c) returns d { > } > > I'll post an update soon. > > > That's certainly a non-intuitive syntax. How about we take a page out of the book of other C-style languages before trying to invent something else? I agree with Stas, "return" and "returns" are not part of a function definition. -- Jeremy Privett C.E.O. & C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. --- ## #37234 — Sam Barrow — 2008-04-25T19:15:44+00:00 URL: https://externals.io/message/37218#37234 · In reply to: #37233 > Sam Barrow wrote: > > […] > > That's certainly a non-intuitive syntax. How about we take a page out of > the book of other C-style languages before trying to invent something > else? I agree with Stas, "return" and "returns" are not part of a > function definition. I don't think it's non-intuitive at all, and even so, it's the most intuitive we have. This ordering makes more sense to me at first glance (in the order I would think about things; scope, name, arguments, return). --- ## #37235 — Nathan Nobbe — 2008-04-25T19:24:56+00:00 URL: https://externals.io/message/37218#37235 · In reply to: #37234 > > > […] > > I don't think it's non-intuitive at all, and even so, it's the most > intuitive we have. This ordering makes more sense to me at first glance (in > the order I would think about things; scope, name, arguments, return). im not sure the following has been explicitly proposed, but how about omitting the 'return' keyword and placing the return type hint before the function identifier function int a($b, $c) {} i think that is most congruent with 'typical' of c style languages, no ? -nathan --- ## #37236 — Sam Barrow — 2008-04-25T19:25:05+00:00 URL: https://externals.io/message/37218#37236 · In reply to: #37235 > > > > […] > page out of > > […] > something > > […] > of a > > […] > > > I don't think it's non-intuitive at all, and even so, it's the > most intuitive we have. This ordering makes more sense to me > at first glance (in the order I would think about things; > scope, name, arguments, return). > > im not sure the following has been explicitly proposed, but how about > omitting the 'return' keyword and placing the return type hint before > the function identifier > > function int a($b, $c) {} > This is, but I don't think this is possible, due to confusion with the keywords (public, private, static, abstract, etc). Plus this leads to long strings of keywords. > i think that is most congruent with 'typical' of c style languages, > no ? > > -nathan --- ## #37238 — Michal Dziemianko — 2008-04-25T21:19:25+00:00 URL: https://externals.io/message/37218#37238 · In reply to: #37236 Hello everybody, I am new here (just reading for last couple of days), so firstly nice to meet you:) This discussion seems quite interesting for me and it would be nice if I can join... Sam Barrow napisal: > > […] > > This is, but I don't think this is possible, due to confusion with the > keywords (public, private, static, abstract, etc). Parser should be able to handle it if the grammar is correct. "something something2 somethign3 int foo(...)" works fine in some languages. LALR parser (Bison is used, isn't it?) is probably the most powerful parser practically used, and certainly can handle such a set of keywords correctly - even without "function" keyword (that makes parsing way easier) - or maybe I have missed some piece of syntax that might cause the problem (then my apologies) As there is a person working on converting parser to Lemon, maybe it would be wise to talk with him (her?), so the grammar is cleaned to handle it. > Plus this leads to > long strings of keywords. imho it is shorter - one keyword less. Actually it is also less confusing for me - maybe because I am using C/C++ and Java a lot where the syntax is equivalent. And if syntax is strict - i.e. modifiers first, then returned type - is quite well-readable - name of the function in the end, returned type just before. The version with "returns" seems to me like "throws" phrase from e.g. Java. Btw there was already such a solution in Pascal, but instead of "returns" colon was used: function foo(...):integer begin ... end Cheers, Michal Dziemianko PS. The idea is great anyways - I was always thinking why it is not implemented:)) --- ## #37237 — Chris Stockton — 2008-04-25T21:22:10+00:00 URL: https://externals.io/message/37218#37237 · In reply to: #37236 > > > […] > > This is, but I don't think this is possible, due to confusion with the > keywords (public, private, static, abstract, etc). Plus this leads to > long strings of keywords. There can be no technical reason why this more adopted and understood syntax should not be possible. Adding returns as a keyword would completely break tons of code. Why are the proposals on something that is so consistent across many languages being changed so obscurely? Why a seperate non-intuitive syntax. public function int (string $foo) { return 1; } Can't we keep the sanity? > [ ... ] Plus this leads to > long strings of keywords. Are you kidding? strlen('returns int') > strlen('int'); ..... -Chris --- ## #37239 — Sam Barrow — 2008-04-25T22:04:22+00:00 URL: https://externals.io/message/37218#37239 · In reply to: #37237 I don't know, maybe it does work. But either way I'm not introducing a new keyword, I changed the patch to reuse the return keyword. Yes, long strings of keywords: abstract protected string function dostuff() > On Fri, Apr 25, 2008 at 12:25 PM, Sam Barrow > wrote: > > > > […] > wrote: > > […] > wrote: > > […] > we take a > > […] > to invent > > […] > are not part > > […] > so, it's the > > […] > sense to me > > […] > things; > > […] > how about > > […] > hint before > > […] > > > This is, but I don't think this is possible, due to confusion > with the > keywords (public, private, static, abstract, etc). Plus this > leads to > long strings of keywords. > > There can be no technical reason why this more adopted and understood > syntax should not be possible. Adding returns as a keyword would > completely break tons of code. Why are the proposals on something that > is so consistent across many languages being changed so obscurely? Why > a seperate non-intuitive syntax. > > public function int (string $foo) { return 1; } > > Can't we keep the sanity? > > > [ ... ] Plus this leads to > long strings of keywords. > > Are you kidding? strlen('returns int') > strlen('int'); ..... > > > -Chris --- ## #37240 — Chris Stockton — 2008-04-25T22:15:15+00:00 URL: https://externals.io/message/37218#37240 · In reply to: #37239 Hello Sam, I think you misunderstand, let me retype for you. strlen('abstract protected function string dostuff()') < strlen('abstract protected function dostuff() return string') Making your argument on length void, also, maybe we should not base a language change decision on typing extra characters.. Sorry man, but to me the code below looks so unusual for what it is meant to represent: abstract protected function bar($foo) return string { // code } The above, actually kind of makes me think something non-conventional is going to happen like return string specifies that it will be auto type casted to a string for me or something. like: abstract protected function bar($foo) return string { return $foo; // is auto magically like: return (string) $foo; } vs the below code that tells me function returns a string like in many popular languages. abstract protected function string bar($foo) { return (string) $foo; } -Chris > I don't know, maybe it does work. But either way I'm not introducing a > new keyword, I changed the patch to reuse the return keyword. > > Yes, long strings of keywords: > > abstract protected string function dostuff() > > > > […] --- ## #37241 — Edward Z. Yang — 2008-04-25T22:47:51+00:00 URL: https://externals.io/message/37218#37241 · In reply to: #37218 Sam Barrow wrote: > Attached is my return type hinting patch. [snip] I have a question independent of syntax/design-concerns: does this patch utilize typed returns to afford performance benefits to userland code that use it? -- Edward Z. Yang GnuPG: 0x869C48DA HTML Purifier Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] --- ## #37242 — Alain Williams — 2008-04-25T23:13:05+00:00 URL: https://externals.io/message/37218#37242 · In reply to: #37237 public function int doThing(string $foo) { return 1; } The above is the best (ie omit 'return' or 'returns'). This also is consistent with C and with the way that the manual is written, eg: http://www.php.net/manual/en/function.strlen.php The only argument is the relative ordering of the keywords. We keep 'function' - since that is the way that the language works. Things like 'public' we put before 'function' since that is the way that it works in PHP 5 objects. So the only thing to decide is where the type goes: public function int doThing(string $foo) { return 1; } or: public int function doThing(string $foo) { return 1; } I would favour the first one, this is probably also easier to parse, as following 'function' and before '(' you can have: * 1 word - which must be the name of the function * 2 words - the first word is the return type, the second the function name. If the function returns a reference to something of a particular type, where does the '&' go: public function &int doThing(string $foo) { return 1; } or: public function int& doThing(string $foo) { return 1; } I would suggest the second, ie just before the function name. -- Alain Williams Linux 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 Chairman of UKUUG: http://www.ukuug.org/ #include public function int doThing(string $foo) { return 1; } > > The above is the best (ie omit 'return' or 'returns'). > > This also is consistent with C and with the way that the manual is written, eg: > > http://www.php.net/manual/en/function.strlen.php > > The only argument is the relative ordering of the keywords. > We keep 'function' - since that is the way that the language works. > Things like 'public' we put before 'function' since that is the way that > it works in PHP 5 objects. > > So the only thing to decide is where the type goes: > > public function int doThing(string $foo) { return 1; } > > or: > > public int function doThing(string $foo) { return 1; } > > I would favour the first one, this is probably also easier to parse, as > following 'function' and before '(' you can have: > > * 1 word - which must be the name of the function > * 2 words - the first word is the return type, the second the function name. > > If the function returns a reference to something of a particular type, where > does the '&' go: > > public function &int doThing(string $foo) { return 1; } > > or: > > public function int& doThing(string $foo) { return 1; } > > I would suggest the second, ie just before the function name. > > -- > Alain Williams > Linux 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 > Chairman of UKUUG: http://www.ukuug.org/ > #include > public function int doThing(string $foo) { return 1; } > > The above is the best (ie omit 'return' or 'returns'). > > This also is consistent with C and with the way that the manual is > written, eg: > > http://www.php.net/manual/en/function.strlen.php > > The only argument is the relative ordering of the keywords. > We keep 'function' - since that is the way that the language works. > Things like 'public' we put before 'function' since that is the way > that > it works in PHP 5 objects. > > So the only thing to decide is where the type goes: > > public function int doThing(string $foo) { return 1; } > > or: > > public int function doThing(string $foo) { return 1; } > > I would favour the first one, this is probably also easier to parse, > as > following 'function' and before '(' you can have: > > * 1 word - which must be the name of the function > * 2 words - the first word is the return type, the second the > function name. > > If the function returns a reference to something of a particular > type, where > does the '&' go: > > public function &int doThing(string $foo) { return 1; } > > or: > > public function int& doThing(string $foo) { return 1; } > > I would suggest the second, ie just before the function name. > > -- > Alain Williams > Linux 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 > Chairman of UKUUG: http://www.ukuug.org/ > #include Wouldn't the most consistent way be to omit "function" altogether when > using a return type hint? > > public static function zomg() { > return $somethingArbitrary; > } > > public static string foo() { > return $mustBeString; > } > i think leaving 'function' in there makes sense because thats the way php currently works. otoh, should there ever be a type "function" (e.g. for anonymous funcs) down > the road, that'd mean trouble ;) wow; good point! maybe if anonymous functions are ever supported the type could be capitalized as in 'Function' public function Function doStuff() { return function() {} } -nathan --- ## #37255 — dz@bitxtender.com — 2008-04-26T23:26:24+00:00 URL: https://externals.io/message/37218#37255 · In reply to: #37254 Am 27.04.2008 um 00:24 schrieb Nathan Nobbe: > On Sat, Apr 26, 2008 at 2:06 PM, David Zülke > wrote: > > > […] > > i think leaving 'function' in there makes sense because thats the > way php > currently works. Well that was my point. Functions without return type hints use "function", to indicate that they are generic in this respect, and functions/methods with a type hint omit it to signal the difference. Having both would be redundant. But then...: > > […] > > > wow; good point! maybe if anonymous functions are ever supported > the type > could be capitalized as in 'Function' > > public function Function doStuff() { > return function() {} > } Absolutely not. Right now, all PHP native types are lowercase. Can't see why anon functions should be different. Actually, both ways have problems: public function gimmeThat() { return function() { echo 'yay'; } } is ambiguous if return type hints require omitting "function", and public function function gimmeThat() { ... } is just plain ugly. So maybe anon funcs should have a different type name :p David --- ## #37256 — Chris Stockton — 2008-04-27T00:11:29+00:00 URL: https://externals.io/message/37218#37256 · In reply to: #37255 *cough* lambda *cough* > Am 27.04.2008 um 00:24 schrieb Nathan Nobbe: > > > > […] > > Well that was my point. Functions without return type hints use > "function", to indicate that they are generic in this respect, and > functions/methods with a type hint omit it to signal the difference. Having > both would be redundant. But then...: > > > otoh, should there ever be a type "function" (e.g. for anonymous funcs) > > […] > > > Absolutely not. Right now, all PHP native types are lowercase. Can't see > why anon functions should be different. > > Actually, both ways have problems: > > public function gimmeThat() { > return function() { echo 'yay'; } > } > > is ambiguous if return type hints require omitting "function", and > > public function function gimmeThat() { > ... > } > > is just plain ugly. > > So maybe anon funcs should have a different type name :p > > > David --- ## #37257 — dz@bitxtender.com — 2008-04-27T00:20:48+00:00 URL: https://externals.io/message/37218#37257 · In reply to: #37256 But anonymous functions and lambda expressions are not the same thing... David Am 27.04.2008 um 02:11 schrieb Chris Stockton: > *cough* lambda *cough* > > On Sat, Apr 26, 2008 at 4:26 PM, David Zülke > wrote: > Am 27.04.2008 um 00:24 schrieb Nathan Nobbe: > > > On Sat, Apr 26, 2008 at 2:06 PM, David Zülke > wrote: > > Wouldn't the most consistent way be to omit "function" altogether when > using a return type hint? > > public static function zomg() { > return $somethingArbitrary; > } > > public static string foo() { > return $mustBeString; > } > > > i think leaving 'function' in there makes sense because thats the > way php > currently works. > > Well that was my point. Functions without return type hints use > "function", to indicate that they are generic in this respect, and > functions/methods with a type hint omit it to signal the difference. > Having both would be redundant. But then...: > > > > otoh, should there ever be a type "function" (e.g. for anonymous > funcs) down > the road, that'd mean trouble ;) > > > wow; good point! maybe if anonymous functions are ever supported > the type > could be capitalized as in 'Function' > > public function Function doStuff() { > return function() {} > } > > > Absolutely not. Right now, all PHP native types are lowercase. Can't > see why anon functions should be different. > > Actually, both ways have problems: > > public function gimmeThat() { > return function() { echo 'yay'; } > } > > is ambiguous if return type hints require omitting "function", and > > public function function gimmeThat() { > ... > } > > is just plain ugly. > > So maybe anon funcs should have a different type name :p > > > David --- Next page: https://externals.io/message/37218.md?page=2