ext/standard/basic_functions.c: add puts function

[ghost]

with PHP, several methods are available to produce output:

echo "hello world\n";
print "hello world\n";
print_r("hello world\n");
var_export("hello world\n");

However all these methods have something in common: they do not produce their
own newline. With each method, the user is required to provide a newline with
\n, PHP_EOL or similar. This is bothersome because many other programming
languages offer such a method. For example Python:

print('hello world')

Perl:

use feature say;
say 'hello world';

Ruby:

puts 'hello world'

Lua:

print 'hello world'

Even C:

#include <stdio.h>
int main() {
   puts("hello world");
}

To resolve, implement "puts" function similar to Ruby or C:

• http://pubs.opengroup.org/onlinepubs/9699919799/functions/puts.html
• http://ruby-doc.org/core/IO.html#method-i-puts

[carusogabriel]

Please, add some tests to test this function's behaviour.

[cmb69]

For reference: discussion on internals@.

[krakjoe]

@cup test fails ...

[cmb69]

@cup, any news? Since this would require an RFC, and PHP 7.4 will reach feature freeze in about six weeks, time to hurry up, if you want to see this in the next minor version.

[petk]

@cup I have fixed my emoji now. Actually, you have missed something here about my reaction (attempt to enlighten the atmosphere and make a more positive feeling of the derailed discussion on the mailing list where your language used there was low quality also - meaning you have a blame there as well). I was in favour of this suggestion. Now, I'm not sure so much anymore... Thank you.

P.S: I've added also a rocket emoji there first and removed it now also ;)

[cmb69]

@cup, every controversial change to PHP needs the RFC process , and this PR is apparently controversial. Without RFC this feature has no change to get merged (well, someone might actually merge it, but certainly somebody else will revert the commit), since we need a vote, and therefore the RFC process. Of course, you are not obliged to actually start the RFC process. The choice is up to you. :)

@petk, I think we all should try to assess any feature proposal solely based on its own merits, regardless of whether we like the proposers face. :)

[petk]

@petk, I think we all should try to assess any feature proposal solely based on its own merits, regardless of whether we like the proposers face. :)

Of course. I agree with that. Reactionless RFC in progress where only value add on matters without any influence of possible supporters or people not in favour. Unless the veto happens by some member of the PHP group.

Considering how many languages out there use something like this already, and that PHP wants to be some sort of better CLI tooling platform in the future also, this feature has a clear 2/3+ majority already (maybe not from the people one might expect on the first glance but from the people one never expected)... Now, if one gives up on the way, then it won't be implemented anyway. World won't break apart in any of these cases here I think.

@cup I can guarantee you that most people that will vote on the RFC will vote only in the best interest of the PHP language as a whole and its progress and not be biased based on couple of awkward discussions and reactions.

Good luck.

[krakjoe]

You have to subscribe in order to take part in the RFC process.

…

On Thu, 13 Jun 2019, 01:42 Steven Penny, ***@***.***> wrote: @petk <https://github.com/petk> I need RFC karma I tried emailing but I was blocked because I am not a subscriber. I do not wish to subscribe as I dont want spam can you please help - thank you — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3918?email_source=notifications&email_token=AARB52R7F3HID6VBGZJOIFDP2GCX5A5CNFSM4G3ULBVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXSDA5I#issuecomment-501493877>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARB52XWJVKUZPQTTKHSLUTP2GCX5ANCNFSM4G3ULBVA> .

[cmb69]

It might still be not necessary to subscribe to the internals@ mailing list; I'm not subscribed either. Instead I'm subscribed to the mirrored news group, and when I first mailed to the internals@ list, I got a message back, which I had to confirm. Maybe it no longer works this way.

[krakjoe]

https://wiki.php.net/rfc/howto You have to subscribe ...

…

On Thu, 13 Jun 2019 at 08:37, Christoph M. Becker ***@***.***> wrote: It might still be not *necessary* to subscribe to the internals@ mailing list; I'm not subscribed either. Instead I'm subscribed to the mirrored news group, and when I first mailed to the internals@ list, I got a message back, which I had to confirm. Maybe it no longer works this way. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3918?email_source=notifications&email_token=AARB52W6LPFSN4FP2TQBHBTP2HTKFA5CNFSM4G3ULBVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXSVPPY#issuecomment-501569471>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARB52VDXLSA4PXBYYKJWHTP2HTKFANCNFSM4G3ULBVA> .

[nicoSWD]

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';

[krakjoe]

I think the choice between a language construct and a function can be a secondary vote in the RFC. It can be implemented, or optimized, as a VM instruction, which again can be decided after we decide if we want the feature, it's an implementation detail we don't need to dwell on.

…

On Fri, 14 Jun 2019 at 10:08, Nico Oelgart ***@***.***> wrote: 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'; — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3918?email_source=notifications&email_token=AARB52QF6Q6YDDI4Y4NTQ73P2NGXZA5CNFSM4G3ULBVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXWBWPY#issuecomment-502012735>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARB52XYUFOQ6BAIDSVK46DP2NGXZANCNFSM4G3ULBVA> .

[petk]

Quick thought, I've forgotten to write on the internals... This

puts('something');

will emit the string something and PHP_EOL which is not what many want. I would expect to have \n on all platforms. Even Windows where \r\n will be written.

Inspiration from Rust: https://doc.rust-lang.org/std/macro.println.html

[ghost]

@petk, no, thats an opinion.

Python print for example does CR+LF on Windows. My preference would be to keep PHP_EOL in place because its the most portable output. Windows users expect CR+LF output, so I would consider Rust and others that are hardcoding LF to be counterexamples.

Of course the final decision isnt up to me, but Im not changing the code to be hardcoded LF, on principle.

[petk]

Different output on different platforms is also tricky for wider use cases of such function/language construct... For example, if puts (together with something like heredoc) will be used to create a file using this php script.php > file.txt then different line endings won't be a portable solution actually for the end user. Using the same line ending will be. Actually, using hardcoding we could all eliminate different line endings across platforms on the long run also but well, just a thought actually more or less. Yes, it won't fit every use case out there that's for sure... P.S. I'm not sure I've met people that wan't to have CRLF in their output. In most cases they are probably unaware of this, or simply want to have entire output in the same line endings (either LF or CLRF)... It won't cause issues in most cases, but it's an option for some annoying bugs out of nowhere.

Well outputs are a thing to think through anyway. I also haven't tested fully all these options or made some list to get a bigger picture about this... So, yeah probably ok I guess...

[nikic]

Inspiration from Rust: https://doc.rust-lang.org/std/macro.println.html

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.)

[krakjoe]

The implementation should really match the proposal in the RFC: close this pull request and create another one.