/**
* 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
*/
==== Reasons to Add This ====
- This is useful for self-contained scripts and a useful helper function to have overall. E.g. phpt tests of php itself print multiple lines for the ''--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())''
- Even if codebases add userland helper equivalents that do exactly this, If you are new to a codebase, or contribute to multiple codebases, it is inconvenient to use ''xyz_println'', ''ABCUtils::println()'', ''echo X, "\n"'', etc., and remember if those different functions actually use the line endings you think they do. \\ Additionally, the prefixing is much more verbose.
- In tutorials or language references that teach a developer how to use php functionality, it is often preferable to use functions that append a newline when multiple snippets would be evaluated together to keep examples simple. \\ ''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"'') \\ E.g. ''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
==== The Unix Newline is always used ====
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 ''<<
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.
==== This may not be commonly used for HTML ====
https://externals.io/message/104545#104560
> 3. Add a new method, perhaps "echoln", "println", "say" or similar, that outputs a newline by default Of 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 '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 ''
' or '
' (depending on the dialect of HTML in use), but you're as likely to want "$foo
", or "$foo ", 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]
'', ''