rfc:flexible_heredoc_nowdoc_syntaxes

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
rfc:flexible_heredoc_nowdoc_syntaxes [2017/09/21 12:02]
tpunt 		rfc:flexible_heredoc_nowdoc_syntaxes [2018/04/13 19:59]
nikic Implementation landed
Line 3: Line 3:
   * Date: 2017-09-16   * Date: 2017-09-16
   * Author: Thomas Punt, tpunt@php.net   * Author: Thomas Punt, tpunt@php.net
-  * Status: Draft+  * Status: Implemented (in PHP 7.3)
   * First Published at: https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes   * First Published at: https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes
  
Line 64: Line 64:
 If the closing marker is indented further than any lines of the body, then a ''ParseError'' will be thrown: If the closing marker is indented further than any lines of the body, then a ''ParseError'' will be thrown:
 <code php> <code php>
-try { + 
-    echo <<<END +echo <<<END 
-      a +  a 
-     b + b 
-    c +c 
-     END; + END; 
-} catch (ParseError $pe) { + 
-    // Parse error: Invalid body indentation level (expecting an indentation at least 5) in %s on line %d +// Parse error: Invalid body indentation level (expecting an indentation at least 5) in %s on line %d
-    var_dump($e->getMessage()); +
-}+
 </code> </code>
  
Line 95: Line 93:
 { {
  echo <<<END  echo <<<END
-  a+   a
  END;  END;
 } }
Line 101: Line 99:
  
 These whitespace constraints have been included because mixing tabs and spaces for indentation is harmful to legibility. These whitespace constraints have been included because mixing tabs and spaces for indentation is harmful to legibility.
 +
 +Ultimately, the purpose of stripping leading whitespace is to allow for the body of the heredoc and nowdoc to be indented to the same level as the surrounding code, without causing unnecessary (and perhaps undesirable) whitespace to prepend each line of the body text. Without this, developers may choose to de-indent the body text to prevent leading whitespace, which leads us back to the current situation of having indentation levels of code ruined by these syntaxes.
  
 ==== Closing Marker New Line ==== ==== Closing Marker New Line ====
  
-Removing the closing marker requirement will change code from:+Currently, in order to terminate a heredoc or nowdoc, a new line **must** be used after the closing marker. Removing this requirement will change code from:
 <code php> <code php>
 stringManipulator(<<<END stringManipulator(<<<END
Line 136: Line 136:
 </code> </code>
  
-This change was actually brought up in a previous RFC ([[rfc:heredoc-scanner-loosening|PHP RFC: Loosening heredoc/nowdoc scanner]]). One of the big gotchas that it mentioned, however, was that if the ending marker was found at the start of a line, then regardless of whether it was apart of another word, it would still be considered as the ending marker. For example, the following would not work:+This change was actually brought up in a previous RFC ([[rfc:heredoc-scanner-loosening|PHP RFC: Loosening heredoc/nowdoc scanner]]). One of the big gotchas that it mentioned, however, was that if the ending marker was found at the start of a line, then regardless of whether it was a part of another word, it would still be considered as the ending marker. For example, the following would not work (due to ''ENDING'' containing ''END''):
 <code php> <code php>
 $values = [<<<END $values = [<<<END
Line 150: Line 150:
 The implementation I am proposing avoids this problem by checking to see if a continuation of the found marker exists, and if so, then if it forms a valid identifier. This means that the terminating marker string will only be considered as such if it is matched exactly as a standalone, valid symbol (that is also found at the start of the line). This enables for the above snippet to now work. The implementation I am proposing avoids this problem by checking to see if a continuation of the found marker exists, and if so, then if it forms a valid identifier. This means that the terminating marker string will only be considered as such if it is matched exactly as a standalone, valid symbol (that is also found at the start of the line). This enables for the above snippet to now work.
  
-Something such as the following will still not work, however:+Examples such as the following will still not work, however:
 <code php> <code php>
 $values = [<<<END $values = [<<<END
Line 159: Line 159:
 /* /*
 Parse error: syntax error, unexpected 'ING' (T_STRING), expecting ']' in %s on line %d Parse error: syntax error, unexpected 'ING' (T_STRING), expecting ']' in %s on line %d
 +*/
 +
 +echo <<<END
 +END{$var}
 +END;
 +/*
 +Parse error: syntax error, unexpected '$var' (T_VARIABLE) in %s on line %d
 */ */
 </code> </code>
  
-(Notice the space after the first ''END''.) There is not a great deal that can be done about this. So the simple rule is: **do not choose a marker that appears in the body of the text** (though it would specifically have to occur at the start of a line in the text to cause problems).+There is not a great deal that can be done about this. So the simple rule is: **do not choose a marker that appears in the body of the text** (though it would specifically have to occur at the start of a line in the text to cause problems).
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
Line 169: Line 176:
  
   * the colliding marker begins at the start of a line in the text   * the colliding marker begins at the start of a line in the text
-  * the colliding marker can be seen as standalone +  * the colliding marker can be seen as standalone, valid symbol name
- +
-The changes proposed in this RFC therefore comes down to whether you believe developers are responsible enough to choose non-colliding markers. I firmly believe that since we give developers the power to choose their own markers, then they should be responsible enough to choose markers that do not collide with the inner multiline text.+
  
-Therefore, I believe the tradeoff of making the heredoc and nowdoc syntaxes more flexible in return for requiring developers to actually choose good marker names is a tradeoff worth making.+The changes proposed by this RFC therefore come down to whether you believe developers are responsible enough to choose non-colliding markers. I firmly believe that since we give developers the power to choose their own markers, then they should be responsible enough to choose markers that do not collide with the inner multiline text.
  
 So to quickly reiterate, the changes proposed by this RFC will enable for code such as the following: So to quickly reiterate, the changes proposed by this RFC will enable for code such as the following:
Line 209: Line 214:
 ===== Proposed Voting Choices ===== ===== Proposed Voting Choices =====
  
-There will be two votes, both requiring a 2/3 majority. The first will be regarding whether the closing marker should be able to be indented. The second will be whether the closing marker should remove the new line requirement. These votes are orthogonal to one-another (it doesn't matter if one fails).+There will be two votes, both requiring a 2/3 majority. The first will be regarding whether the closing marker can be indented. The second will be whether the closing marker should remove the new line requirement. These votes are orthogonal to one-another (if one fails and the other passes, then the other still passes). 
 + 
 +Voting starts on 2017.11.01 and ends on 2017.11.15. 
 + 
 +<doodle title="Allow for the closing marker to be indented and for the leading whitespace to be stripped?" auth="tpunt" voteType="single" closed="true"> 
 +   * Yes 
 +   * No 
 +</doodle> 
 +'''' 
 +<doodle title="Remove the trailing new line requirement from the closing marker?" auth="tpunt" voteType="single" closed="true"> 
 +   * Yes 
 +   * No 
 +</doodle>
  
 ===== Patches and Tests ===== ===== Patches and Tests =====
rfc/flexible_heredoc_nowdoc_syntaxes.txt · Last modified: 2018/04/13 19:59 by nikic

Page Tools