Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision |
rfc:println [2021/03/13 19:16] – tandre | rfc:println [2021/03/13 20:03] – tandre |
---|
* Date: 2021-03-13 | * Date: 2021-03-13 |
* Author: Tyson Andre | * Author: Tyson Andre |
* Status: Draft | * Status: Under Discussion |
* First Published at: http://wiki.php.net/rfc/println | * First Published at: http://wiki.php.net/rfc/println |
| * Implementation: https://github.com/php/php-src/pull/6639 |
| |
===== Introduction ===== | ===== Introduction ===== |
The behavior is equivalent to the following polyfill but expected to be more efficient due to avoiding concatenation. | The behavior is equivalent to the following polyfill but expected to be more efficient due to avoiding concatenation. |
| |
Similarly to https://www.php.net/manual/en/function.printf.php#refsect1-function.printf-returnvalues - this returns the number of bytes that were **successfully** output to stdout to be consistent with ''printf''. In the typical case where there was no output error, this returns ''strlen($data) + 1''. (E.g. printf and println may fail if php's standard output was redirected to a file on a disk that filled up) | Similarly to https://www.php.net/manual/en/function.printf.php#refsect1-function.printf-returnvalues - this returns the number of bytes that were **successfully** output to stdout (to be consistent with ''printf''). In the typical case where there was no output error, this returns ''strlen($data) + 1''. (E.g. printf and println may fail if php's standard output was redirected to a file on a disk that filled up) |
| |
| |
Within HTML, there are elements such as ''<pre>'', ''<textarea>'', ''<script>'', etc. where newlines are needed and used instead of ''<br>'' | Within HTML, there are elements such as ''<pre>'', ''<textarea>'', ''<script>'', etc. where newlines are needed and used instead of ''<br>'' |
| |
===== Proposed Voting Choices ===== | ==== Choice of println for the name ==== |
Yes/No, requiring 2/3 majority. | |
| |
===== References ===== | Naming was discussed in a different user's proposal to add a "puts" function that was never brought to a vote. https://github.com/php/php-src/pull/3918#issuecomment-502241701 |
https://externals.io/message/104545 "print with newline" | |
| |
===== Rejected Features ===== | <blockquote> |
| nikic commented on 14 Jun 2019 |
| |
==== Alternate names ==== | > Inspiration from Rust: https://doc.rust-lang.org/std/macro.println.html |
| |
''println'' was deliberately chosen over ''puts'' - the name ''puts'' could be argued to be unfamiliar to | Speaking of ... I think it would make a lot more sense to call this function println rather than puts. The fact that puts() is like print but with a newline will not be obvious to anyone without a C background. (Or even to someone with a C background for that matter, I haven't ever used this function and wouldn't know that it adds a newline.) |
anyone without a C background. Several new languages such as golang/rust (and older languages like java(different semantics)) have gone with ''println'' instead. | </blockquote> |
| |
| As stated in that comment, new languages such as golang/rust (and older languages like java(different semantics)) have gone with ''println'' instead. |
Additionally, the fact that ''puts'' would append newlines and ''fputs'' [[https://www.php.net/fputs|does not]] (exactly the same as it does in C) is something that I'd expect to be a source of confusion if the name ''puts'' was used. | Additionally, the fact that ''puts'' would append newlines and ''fputs'' [[https://www.php.net/fputs|does not]] (exactly the same as it does in C) is something that I'd expect to be a source of confusion if the name ''puts'' was used. |
| |
(e.g. changing ''puts("test")'' to ''fputs(STDERR, "test")'' would unexpectedly not print a terminating newline to STDERR (''fputs'' is an alias of ''fwrite'')) | (e.g. changing ''puts("test")'' to ''fputs(STDERR, "test")'' would unexpectedly not print a terminating newline to STDERR (''fputs'' is an alias of ''fwrite'')) |
| |
| ==== Choice of Unix newline(\n) ==== |
| |
| Some programming languages such as Java use a platform-specific or configurable newline https://docs.oracle.com/javase/6/docs/api/java/io/PrintStream.html#println%28%29 |
| Others, such as rust and golang, always use a unix newline. |
| |
| There have been some comments in favor of Unix newlines, and other comments in favor of PHP_EOL or configurable settings - e.g. https://externals.io/message/104545 |
| |
| My reasons for unconditionally choosing the Unix newline are documented in the section [[#the_unix_newline_is_always_used|The Unix Newline is always used]]. |
| |
| ==== Should this be a language construct instead ==== |
| |
| |
| https://github.com/php/php-src/pull/3918#issuecomment-502012735 |
| |
| <blockquote> |
| Should't this be a language construct instead of a function, so it can be used without parenthesis just like echo or print? |
| |
| It would feel a little weird being able to do: |
| |
| <code php> |
| echo 'hello world'; |
| print 'hello world'; |
| </code> |
| ... but not: |
| |
| <code php> |
| puts 'hello world'; |
| </code> |
| </blockquote> |
| |
| Adding this as a language construct (i.e. new statement type) is something I'd expect to be contentious, and this is deliberately NOT done. Adding a new keyword would |
| |
| - Cause a larger BC break. |
| - Increase the complexity of the language specification and make the language a bit harder to learn; I'd prefer simplicity by using an ordinary global function in this case. |
| - Be impossible to polyfill (when brackets weren't added) for older php versions. |
| |
| ===== Proposed Voting Choices ===== |
| Yes/No, requiring a 2/3 majority. |
| |
| ===== References ===== |
| https://externals.io/message/104545 "print with newline" |
| |
| https://github.com/php/php-src/pull/3918 "ext/standard/basic_functions.c: add puts function" has discussion on a similar proposal by a different author. My RFC uses ''\n'', while the other author's RFC proposed ''PHP_EOL''. |