rfc:scalar_type_hints_v5
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
rfc:scalar_type_hints_v5 [2015/02/18 23:37] – typo ircmaxell | rfc:scalar_type_hints_v5 [2017/09/22 13:28] – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== PHP RFC: Scalar Type Declarations ====== | ====== PHP RFC: Scalar Type Declarations ====== | ||
- | * Version: 0.5.1 | + | * Version: 0.5.3 |
* Date: 2015-02-18 | * Date: 2015-02-18 | ||
* Author: Anthony Ferrara < | * Author: Anthony Ferrara < | ||
- | * Status: | + | * Status: |
* First Published at: http:// | * First Published at: http:// | ||
* Forked From: http:// | * Forked From: http:// | ||
Line 125: | Line 125: | ||
The table shows which types are accepted and converted for scalar type declarations. '' | The table shows which types are accepted and converted for scalar type declarations. '' | ||
- | ^ Type declaration | + | ^ Type declaration |
- | ^ '' | + | ^ '' |
- | ^ '' | + | ^ '' |
- | ^ '' | + | ^ '' |
- | ^ '' | + | ^ '' |
< | < | ||
Line 145: | Line 145: | ||
These strict type checking rules are used for userland scalar type declarations, | These strict type checking rules are used for userland scalar type declarations, | ||
- | The one exception is that [[http:// | + | The one exception is that [[http:// |
<file php widening.php> | <file php widening.php> | ||
Line 159: | Line 159: | ||
In this case, we're passing an '' | In this case, we're passing an '' | ||
+ | |||
+ | No other conversions are allowed. | ||
+ | |||
+ | ==== Error Handler Behavior In Strict Mode ==== | ||
+ | |||
+ | Currently it's possible to bypass error check failures using an error handler: | ||
+ | |||
+ | <file php error_handler_fail.php> | ||
+ | <?php | ||
+ | declare(strict_types=1); | ||
+ | set_error_handler(function() { | ||
+ | return true; | ||
+ | }); | ||
+ | |||
+ | function foo(int $abc) { | ||
+ | var_dump($abc); | ||
+ | } | ||
+ | foo(" | ||
+ | ?> | ||
+ | </ | ||
+ | |||
+ | This would defeat the purpose of strict typing. | ||
+ | |||
+ | Therefore, this RFC proposes to bypass function execution in strict mode if there' | ||
+ | |||
===== Example ===== | ===== Example ===== | ||
Line 378: | Line 403: | ||
In line with [[http:// | In line with [[http:// | ||
- | It however also means that narrowing conversions (float-> | + | It however also means that narrowing conversions (float-> |
+ | |||
+ | Note: If you read the Java spec, you'll notice that it does mention narrowing conversions. It only allows them in assignment or explicit casts however. So they do not apply in the case this proposal puts forward. | ||
==== Weak Should Error On "10 Birds" Style-Strings Passed To Int Parameters ==== | ==== Weak Should Error On "10 Birds" Style-Strings Passed To Int Parameters ==== | ||
Line 491: | Line 518: | ||
=== Current Position === | === Current Position === | ||
- | There are two problems with using one of the proposed alternates: | + | The declare system was designed precisely for this style of engine switch. Additionally, |
- | * All are generic " | + | There are also problems with using each of the proposed alternates: |
- | * All require either re-interpreting existing syntax or creating new and foreign syntax. | + | |
- | The declare system was designed precisely for this style of engine switch. Additionally, | + | * ''<? |
+ | |||
+ | This is new syntax, which is potentially ambiguous around what " | ||
+ | |||
+ | Additionally, | ||
+ | |||
+ | * ''<? | ||
+ | |||
+ | This opens the door for potential code disclosure vulnerability if run on an earlier version of PHP (since the ''<? | ||
+ | |||
+ | * '' | ||
+ | |||
+ | Re-using namespaces to affect runtime is weird. Not to mention what's the expected behavior of block mode: | ||
+ | |||
+ | <file php use_strict.php> | ||
+ | <?php | ||
+ | namespace Foo { | ||
+ | use strict; | ||
+ | } | ||
+ | |||
+ | namespace { | ||
+ | bar(); | ||
+ | } | ||
+ | ?> | ||
+ | </ | ||
+ | |||
+ | is bar() called | ||
+ | |||
+ | * ''<? | ||
+ | |||
+ | Comments should not affect runtime behavior. HHVM uses it as they need to affect behavior while remaining compatible with PHP. We do not have that problem. | ||
+ | |||
+ | * '' | ||
+ | |||
+ | Which had a number of people against it, with arguments about the odd behavior of declare in blocks, etc. It does not respect scope, so calling it in one function would transparently effect all future | ||
+ | |||
+ | * '' | ||
+ | |||
+ | <file php strict_namespace.php> | ||
+ | <?php | ||
+ | strict namespace Foo { | ||
+ | |||
+ | } | ||
+ | |||
+ | namespace { | ||
+ | bar(); | ||
+ | } | ||
+ | ?> | ||
+ | </ | ||
+ | |||
+ | This has the same issues as use strict above. However, it also seems to imply that the namespace is strict, where it's only the declarations in the file that are. | ||
==== Why Not Allow Block-Mode For Declare ==== | ==== Why Not Allow Block-Mode For Declare ==== | ||
Line 515: | Line 591: | ||
Allowing strict " | Allowing strict " | ||
- | Therefore, this proposal explicitly disallows changing the type mode anywhere within the file except the first line. Since the first line is the only allowed type change, block mode does not make sense (as there could only ever be a single block in the file). | + | Therefore, this proposal explicitly disallows changing the type mode anywhere within the file except the first line. Since the first line is the only allowed type change, block mode does not make sense (as there could only ever be a single block in the file). |
+ | |||
+ | Additionally, | ||
==== Internal Functions Do Not Have Declared Return Types ==== | ==== Internal Functions Do Not Have Declared Return Types ==== | ||
Line 562: | Line 640: | ||
=== Current Position === | === Current Position === | ||
+ | https:// | ||
This is not a two-part proposal. The proposal is of a unified system that was designed to work together. As such, neither part (weak-only or strict-only) is designed to stand on its own without the other part. | This is not a two-part proposal. The proposal is of a unified system that was designed to work together. As such, neither part (weak-only or strict-only) is designed to stand on its own without the other part. | ||
Line 602: | Line 680: | ||
===== Proposed PHP Version(s) ===== | ===== Proposed PHP Version(s) ===== | ||
- | This is proposed for the next PHP x, currently PHP 7. The acceptance for said version will depend on timing | + | This proposal targets |
===== RFC Impact ===== | ===== RFC Impact ===== | ||
Line 625: | Line 703: | ||
As this is a language change, this RFC requires a 2/3 majority to pass. | As this is a language change, this RFC requires a 2/3 majority to pass. | ||
+ | |||
+ | <doodle title=" | ||
+ | * Yes | ||
+ | * No | ||
+ | </ | ||
+ | |||
+ | This vote is opened on February 26th, 2015 and will close March 16th at 21:00 UTC as announced on list. | ||
===== Patches and Tests ===== | ===== Patches and Tests ===== | ||
Line 646: | Line 731: | ||
===== Changelog ===== | ===== Changelog ===== | ||
+ | * v0.5.3 Change version target back and add line about bypassing function execution on type error in strict mode | ||
+ | * v0.5.2 Change version target | ||
* v0.5.1 Remove aliases from proposal | * v0.5.1 Remove aliases from proposal | ||
* v0.5 Fork from Andrea' | * v0.5 Fork from Andrea' |
rfc/scalar_type_hints_v5.txt · Last modified: 2018/10/17 11:38 by carusogabriel