rfc:negative-string-offsets

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
rfc:negative-string-offsets [2016/01/23 13:37] – created francoisrfc:negative-string-offsets [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 1: Line 1:
-====== PHP RFC: Your Title Here ====== +====== PHP RFC: Generalize support of negative string offsets ====== 
-  * Version: 0.9 +  * Version: 1.3 
-  * Date: 2013-02-24 (use today's date here) +  * Date: 2016-02-18 
-  * Author: Your Name, your_email_address@example.com +  * Author: François Laupretre <francois@php.net> 
-  * Status: Draft (or Under Discussion or Accepted or Declined) +  * Status: Implemented (in PHP 7.1) 
-  * First Published at: http://wiki.php.net/rfc/your_rfc_name+  * First Published at: http://wiki.php.net/rfc/negative-string-offsets
  
-This is a suggested template for PHP Request for Comments (RFCs). Change this template to suit your RFC.  Not all RFCs need to be tightly specified.  Not all RFCs need all the sections below. +===== Introduction =====
-Read https://wiki.php.net/rfc/howto carefully!+
  
 +In most PHP functions, providing a negative value as string offset means '//n// positions counted backwards from the end of the string'.
 +This mechanism is widely used but, unfortunately, these negative values are not supported everywhere this would make sense.
 +So, as PHP developers cannot easily know whether a given string functions accepts negative values or not,
 +they regularly need to refer to the documentation.
 +If it does not, they need to insert a call to the substr() function, making their code less readable and slower.
  
-Quoting [[http://news.php.net/php.internals/71525|Rasmus]]:+An obvious example is strrpos() accepting negative offsets, while strpos() does not. 
 +The same with substr_count() rejecting negative offset or length, when substr() accepts them.
  
-> PHP is and should remain: +===== Proposal =====
-> 1) a pragmatic web-focused language +
-> 2) a loosely typed language +
-> 3) a language which caters to the skill-levels and platforms of a wide range of users+
  
-Your RFC should move PHP forward following his vision. As [[http://news.php.net/php.internals/66065|said by Zeev Suraski]] "Consider only features which have significant traction to a +This RFC proposes to generalize support for negative string offsets everywhere it makes sense.
-large chunk of our userbase, and not something that could be useful in some +
-extremely specialized edge cases [...] Make sure you think about the full context, the huge audience out there, the consequences of  making the learning curve steeper with +
-every new feature, and the scope of the goodness that those new features bring."+
  
-===== Introduction ===== +In accordance with the existing behavior, a negative offset is a position counted backwards from the end of the string.
-The elevator pitch for the RFC. The first paragraph in this section will be slightly larger to give it emphasis; please write a good introduction.+
  
-===== Proposal ===== +In the same spirit, the RFC also adds support for negative length arguments where it makes sense. 
-All the features and examples of the proposal.+A negative length (-//x//) means 'up to the position //x// counted backwards from the end of the string'.
  
-To [[http://news.php.net/php.internals/66051|paraphrase Zeev Suraski]], explain hows the proposal brings substantial value to be considered +The reference behavior for negative offset and length is the [[http://php.net/manual/en/function.substr.php|substr()]] function.
-for inclusion in one of the world's most popular programming languages.+
  
-Remember that the RFC contents should be easily reusable in the PHP Documentation.+The main objective of this RFC is to improve the overall consistency of the language. 
 + 
 +==== Feature requests solved by this RFC ==== 
 + 
 +  * https://bugs.php.net/bug.php?id=50649 
 +  * https://bugs.php.net/bug.php?id=36524 
 + 
 +===== Detailed changes ===== 
 + 
 +==== In the language ==== 
 + 
 +String access to individual characters using a '{}' or '[]' will be extended to negative values. 
 + 
 +Examples : 
 + 
 +<code php> 
 +$str='abcdef'; 
 +var_dump($str[-2]); // => string(1) "e" 
 + 
 +$str{-3}='.'; 
 +var_dump($str); // => string(6) "abc.ef" 
 + 
 +var_dump(isset($str{-4})); // => bool(true) 
 + 
 +var_dump(isset($str{-10})); // => bool(false) 
 +</code> 
 + 
 +==== In built-in functions ==== 
 + 
 +^ Function ^ Add support for ^ 
 +| strpos | Negative offset | 
 +| stripos | Negative offset | 
 +| substr_count| Negative 'offset' and 'length' (same behavior as substr()) | 
 +| grapheme_strpos | Negative offset | 
 +| grapheme_stripos | Negative offset | 
 +| grapheme_extract | Negative offset | 
 +| iconv_strpos | Negative offset | 
 +| file_get_contents| Negative offset (based on seek(SEEK_END), reserved to seekable streams) | 
 +| mb_strimwidth | Negative 'start' and 'width' | 
 +| mb_ereg_search_setpos| Negative 'position' when search string is defined | 
 +| mb_strpos| Negative offset | 
 +| mb_stripos| Negative offset | 
 + 
 +==== Notes ==== 
 + 
 +  * Nothing done for iconv_strrpos() because function does not accept an 'offset' arg (inconsistent with every other xxx_strrpos() functions but argument cannot be added without breaking BC). 
 + 
 +  * file_get_contents() : 'maxlen' argument cannot support negative values because of stream filters.
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
-What breaks, and what is the justification for it?+ 
 +This RFC extends the range of valid values. 
 +In most cases, negative values raise a warning message and offset is considered as zero. 
 +The new behavior considers such values as valid (as long as they don't exceed the string length). 
 + 
 +While not negligible, I consider these BC breaks as minor because, everywhere the behavior is modified, negative values were considered as invalid and raised an error message. 
 +So, we are just suppressing error cases.
  
 ===== Proposed PHP Version(s) ===== ===== Proposed PHP Version(s) =====
-List the proposed PHP versions that the feature will be included in.  Use relative versions such as "next PHP 7.x" or "next PHP 7.x.y".+ 
 +7.1
  
 ===== RFC Impact ===== ===== RFC Impact =====
 ==== To SAPIs ==== ==== To SAPIs ====
-Describe the impact to CLI, Development web server, embedded PHP etc.+ 
 +None
  
 ==== To Existing Extensions ==== ==== To Existing Extensions ====
-Will existing extensions be affected?+ 
 +None
  
 ==== To Opcache ==== ==== To Opcache ====
-It is necessary to develop RFC's with opcache in mind, since opcache is a core extension distributed with PHP. 
  
-Please explain how you have verified your RFC's compatibility with opcache.+None
  
-==== New Constants ==== +===== Open Issues =====
-Describe any new constants so they can be accurately and comprehensively explained in the PHP documentation.+
  
-==== php.ini Defaults ==== +To do (waiting for RFC approval) :
-If there are any php.ini settings then list: +
-  * hardcoded default values +
-  * php.ini-development values +
-  * php.ini-production values+
  
-===== Open Issues ===== +  * Update documentation 
-Make sure there are no open issues when the vote starts!+  * Update language specifications
  
 ===== Unaffected PHP Functionality ===== ===== Unaffected PHP Functionality =====
-List existing areas/features of PHP that will not be changed by the RFC. 
  
-This helps avoid any ambiguity, shows that you have thought deeply about the RFC's impact, and helps reduces mail list noise.+mbstring functions remain compatible with their ASCII counterpart, relative to the mbstring.func_overload ini setting.
  
 ===== Future Scope ===== ===== Future Scope =====
-This sections details areas where the feature might be improved in future, but that are not currently proposed in this RFC.+ 
 +==== Recommend using '{}' vs '[]' for string offsets ==== 
 + 
 +It was suggested during the discussion that, since array access and string 
 +offsets are very different operations, the official documentation should 
 +recommend using the '{}' syntax for string offsets, instead of the ambiguous 
 +'[]' syntax (and potentially deprecate '[]' for string offsets in the future). 
 + 
 +On the opposite side, it was also suggested that array access and string offsets 
 +are so closely-related concepts that we should recommend using '[]' in both 
 +cases and disable the alternate '{}' syntax for string offsets ! 
 + 
 +So, as the subject is controversial and very tangential to the subject of this RFC, 
 +it will be left for a future RFC.
  
 ===== Proposed Voting Choices ===== ===== Proposed Voting Choices =====
-Include these so readers know where you are heading and can discuss the proposed voting options. 
  
-State whether this project requires a 2/3 or 50%+1 majority (see [[voting]])+As this RFC adds support for negative string offsets in the language, it requires a 2/3 majority.
  
-===== Patches and Tests ===== +<doodle title="Generalize support of negative string offsets" auth="francois" voteType="single" closed="true"> 
-Links to any external patches and tests go here.+   * Yes 
 +   * No 
 +</doodle>
  
-If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed.+===== Patches and Tests =====
  
-Make it clear if the patch is intended to be the final patch, or is just a prototype.+Pull Request : [[https://github.com/php/php-src/pull/1431]] (final patch)
  
 ===== Implementation ===== ===== Implementation =====
Line 90: Line 150:
  
 ===== References ===== ===== References =====
-Links to external references, discussions or RFCs+None
  
 ===== Rejected Features ===== ===== Rejected Features =====
 Keep this updated with features that were discussed on the mail lists. Keep this updated with features that were discussed on the mail lists.
rfc/negative-string-offsets.1453556278.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools