Hi!
would make even less sense, since it would need to be cast, so the following would return false:function foo((string) $bar = 123) { return $bar === 123; } foo();
You explicitly said "convert, then compare excluding conversion", what would you expect? That's like saying "why $a+1 is not equal to $a, it's almost the same?". No it's not - you just told PHP to modify it!
How much more confusing is that? By restricting the default parameter to be of the type being casted to, that sort of a problem wouldn't happen and would be adverted by the compiler...
I feel you're painting yourself into a corner here - inventing arbitrary restrictions and then inventing arbitrary problems to justify these restrictions. Why would your conversion convert, but not always convert? Why it would work with constants, but not in defaults?
It is proper PHP code. It parses just fine (http://codepad.viper-7.com/rEHqZp). Sure, it's not best practice
The fact it parses doesn't mean it is proper code. The fact it's not errors out is actually a bug, as such function definition is broken. But let's not take the discussion too far out - just please do not promote such code in our RFCs.
The compiler (and any IDE) knows what the type of the variable will be inside the function body. How is that not hinting?
Hinting means something that is just for information and can be ignored it you don't need it. This is type coercion - you can not ignore it, it would change your variables. Calling it hinting implies it does not do anything, just informs IDE - that'd what PHPDoc does, but that's not what your proposed function does. Proper naming is important. The compiler BTW doesn't know anything and has no way to know it and benefit from it in any way.
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
