I apologize: my baby managed to send my email premature. I'm not even sure what hotkey he hit ^^
>> Except `static function()` and `static function foo()` already have >> meaning, and if we allowed static return types (very possible) that >> would be ambiguous. This syntax is a no-go. > > If it is possible, why it's not the part of the RFC? Probably because > there's not much place where it would make sense. So, the only > objections so far have been: <snip> > 3. We could somehow in some undefined time in the future allow static > there, even though we're designing it right now and we actually *do not* > allow it and see no reason to allow it. You seem to be under the assumption that I have designed this as THE RFC for return types, and there will be no others. Quite the contrary: it has been designed to be incredibly minimal, and has taken into consideration possible expansions and allowed for them to work. Other examples not already included are generics and function signatures as types. What arguments do you have in favor of doing `<return_type> "function" <identifier> "( <parameter_list> ")`? So far I haven't heard any argument *for* them that is different than the ones *against* them, but on top of that I have a real, possible technical reason against that way. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
