I reformatted Stas' arguments to a form better for point-by-point discussion; I'm sorry if I lost too much information when doing so.
1) It's more "natural" to do a prefixed type. This is the same thing that I am claiming, just from the opposite viewpoint. 2) Type prefixed parameters and type suffixed returns is unprecedented, outside of Hack. C++11 adds suffixed types for returns despite having prefixed types for everything else, including previous return types. 3) Claiming compatibility for things which aren't proposed is meaningless. People have already asked for support for static return types; doing `<return_type> "function" <identifier> "( <parameter_list> ")` would then be ambiguous. This is not some pie-in-the sky issue. I understand why people might think that compatibility for generics is meaningless, and can respect that (however, C++ templates and Java generics are not good examples of how things work, but I see no point in discussing it in this context; message me off-list if anyone is interested in talking about it). Once again I apologize if I haven distilled Stas' arguments incorrectly. ----- In summary, and relevant to the point of the original discussion: prefixed return types are just not possible if we want to support 'static' return types and keep the ability the current search semantics for function declarations. Or rather, nobody has proposed something that would work for both outside of what I am suggesting in the return type RFC. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
