Printing a string followed by a newline to stdout is a commonly performed operation in many applications. Many programming languages provide a helper function to do this specifically, for readability and convenience. The choice of end of line may differ, but many recent programming languages will unconditionally use the unix newline, to avoid unexpected differences in behavior between platforms.
System.out.println('hello world')print('hello world') prints a newline by default, and a named argument can override that.puts(“hello world”)fmt.Println(“hello world”)println!(“hello world”)However, PHP currently does not yet have a standalone helper method to do this.
Add a global function println(string $data = “”): int to PHP.
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)
/** * Prints $data followed by a unix newline * @return int the number of bytes that were successfully printed to stdout. */ function println(string $data = ''): int { return printf("%s\n", $data); } println("test"); println(); // moderately useful to not switch to echo or pass the empty string to print a blank line println("third line"); /* Output: test third line */
--EXPECT-- section, and var_dump can be overused even for known strings known not to have special characters or spaces because var_dump(some_function()) is a bit simpler to write than echo some_function() . “\n”;, but not as simple as println(some_function())xyz_println, ABCUtils::println(), echo X, “\n”, etc., and remember if those different functions actually use the line endings you think they do. println(“Hello $name”); would be useful to have for introducing PHP to a new developer before echo “Hello $name\n”; (requires explaining control characters first) or var_dump(“Hello $name”); (that debug representation is rarely useful for string(11) “Hello world”) var_dump is frequently used instead of var_export, echo, or print in the manual even for printing strings with no control characters such as https://www.php.net/manual/en/function.json-encode.php#example-3972
This deliberately always prints the unix newline (\n)
instead of PHP_EOL, for the reasons mentioned in this section.
I would find it very unexpected if println were to behave
differently based on the web server was running it,
e.g. if you moved a website's backend from/to a Linux server
to/from a Windows server, responses generated by println would
suddenly be different. (Content-Length, hashes(e.g. sha256 sum) of output, etc.)
Additionally, https://www.php-fig.org/psr/psr-2/ recommends that all php
source files contain unix line endings.
If those files contain inline html/text snippets mixed with php+println(),
or if they contained strings using <<<EOT heredoc,
it would be inconsistent to have \r\n in the lines printed by
println() and \n for heredoc and HTML when running on Windows.
The unix newline is same choice of line ending that var_dump, debug_zval_dump,
and var_export use for dumping output.
Otherwise, println(“myArray=” . var_export($myArray, true));
would be a mix of multiple line ending choices.
PHP's interactive shell (php -a) also prints a single newline character if the output does not end in a newline.
// ext/readline/readline_cli.c if (!pager_pipe && php_last_char != '\0' && php_last_char != '\n') { php_write("\n", 1); }
Many new languages have elected to always use only the unix newlines, e.g. https://golang.org/pkg/fmt/#Println and https://doc.rust-lang.org/std/macro.println.html
Overall, editors do a much better job of detecting newline choices and displaying different newline choices than they did decades ago.
My opinion is that this anything generating files targeting a specific OS's line endings should continue to use PHP_EOL or continue to base the newline choice on the OS of the user requesting the output.
Type checking is done the same way as other ordinary user-defined or internal global functions.
println(1); or println(true) would have the argument coerced to a string when strict_types is disabled (the default), but would be a thrown Error with strict_types=1 (like printf would for the format string).
Depending on the application, this may be useful as a runtime assertion or in making it clear to the reader that the argument is expected to be a string.
println((string) $value); should be used when strict_types=1 but you are uncertain of the type.
(or other alternatives such as echo $arg, “\n”, echo “$arg\n”;, or printf(“%s\n”, $arg))
Declaring a function named println() in the global namespace would become a duplicate function error.
PHP 8.1
Other printing functions or statements are unaffected.
println is deliberately NOT a keyword (e.g. functions named println can continue to be declared outside of the global namespace).
https://externals.io/message/104545#104548
<?php function println(string $x): void { echo $x, PHP_EOL; }I hereby grant a public domain license to the above code and wish you godspeed bundling it into a composer package to be enjoyed by users of every active version of PHP.
-Sara
In practice, I haven't seen many widely used composer packages that contain a small number of functions - PHP tends to be a batteries included language. Additionally, this increases startup times in situations where opcache and/or opcache preloading isn't feasible to set up (especially due to the lack of function autoloading).
A new contributor to a project might not even be aware the helper method is available in a dependency, or of the choice of newline used in a helper method.
If multiple composer packages were published and declared println (in the global namespace) with different behaviors, that would lead to confusion and bugs, which could be avoided by declaring println in PHP itself.
https://externals.io/message/104545#104560
3. Add a new method, perhaps “echoln”, “println”, “say” or similar, that outputs a newline by defaultOf the suggestions put forward, this is the only one I can see having any chance of succeeding.
However, I think the big reason this doesn't already exist is one that's been touched on by other responses: PHP started as, and is still primarily regarded as, a language for building websites. In that context, newline characters are generally considered “insignificant whitespace”; the closest equivalent would be appending '<br>' or '<br />' (depending on the dialect of HTML in use), but you're as likely to want “<p>$foo</p>”, or “<li>$foo</li>”, etc - and that's before we get into the tricky topic of escaping.
Even in CLI scripts, as soon as you're building anything intended for reuse, you're likely to write a function like log_string() which adds information like timestamp, category, severity. The use cases for a new function / keyword may therefore be rather limited.
Regards,
-- Rowan Collins [IMSoP]
Some CLI scripts would use a specialized helper, but not all of them, and a helper may be used in some places but not others. Some CLI scripts are distributed without any external dependencies and the addition of println would simplify them and make them easier to read.
Even when used as a web server, PHP would also serve resources with non-HTML content types such as Content-Type: text/plain (e.g. health checks).
Within HTML, there are elements such as <pre>, <textarea>, <script>, etc. where newlines are needed and used instead of <br>
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
nikic commented on 14 Jun 2019
Inspiration from Rust: https://doc.rust-lang.org/std/macro.println.htmlSpeaking 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.)
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 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))
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.
https://github.com/php/php-src/pull/3918#issuecomment-502012735
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:
echo 'hello world'; print 'hello world';... but not:
puts 'hello world';
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
https://externals.io/message/113504#113530
This isn't solving any problem that anyone is actually having. Yes, that includes you. You're not having this problem because it doesn't exist.
We already have twice as many ways to output a string as any language needs and you want to add another because you'd rather type “LN” than “\N” ? Hard, negative ten thousand no on this. This is genuinely absurd.
Yes/No, requiring a 2/3 majority.
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.