Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113514
To: internals@lists.php.net
References: <DM6PR07MB66189850774C52F7F93989B2F96E9@DM6PR07MB6618.namprd07.prod.outlook.com>
Message-ID: <ff3a7975-770e-2a63-57e8-553fb1fad0ae@gmail.com>
Date: Sun, 14 Mar 2021 14:09:25 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <DM6PR07MB66189850774C52F7F93989B2F96E9@DM6PR07MB6618.namprd07.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] RFC: Add `println(string $data = ''): int`
From: rowan.collins@gmail.com (Rowan Tommins)

On 13/03/2021 19:54, tyson andre wrote:
> I've created a new RFC https://wiki.php.net/rfc/println
> This proposes adding a global function to PHP to
> print a string followed by a unix newline (`\n`).


Hi Tyson,

I'm on the fence on this one: I've certainly had occasions when it would 
be useful, but mostly in quick prototypes and demo code, and just as 
often in HTML context (where I'd want it to add '<br>') as plain text 
context.

I am not keen, however, on the proposed implementation details, and 
would prefer it to much more closely match either print or echo.


- Until reading this RFC, I would not have guessed that printf() 
returned the number of bytes written; I guess it's useful in C, where 
you're managing string buffers, but in PHP it feels very arbitrary. I 
would also not particularly associate this new function with printf() so 
my immediate guess would be the same return value as print (even though 
that return value, int(1), is equally arbitrary).

- You explicitly state that this function would depend on strict_types 
mode, but echo and print do not. I can't see any particular advantage to 
doing so, and 'println((string)$foo)' would be longer than 'print 
$foo,"\n"' rather defeating the purpose.

- Most importantly, I accept your points about a function being more 
forward- and backward-compatible, but worry that not making it a keyword 
will lead to further confusion about how parentheses interact with echo 
and print. There is a common misconception that they have some kind of 
"optional parentheses", because they are usually used with a single 
expression, so wrapping it in parentheses usually doesn't change the 
outcome; but this is not the case, and it does sometimes matter.


As currently proposed, I can see people getting nasty surprises from 
these inconsistencies. For instance:

print (1+2)*3; // prints "9"
println (1+2)*3; // prints "3\n"; unless strict_types=1 is in effect, in 
which case TypeError

print ($foo ?? 'Foo') . ($bar ?? 'Bar'); // prints "FooBar" if both vars 
are null
println ($foo ?? 'Foo') . ($bar ?? 'Bar'); // never prints $bar or 
"Bar", because they are not passed to println()

if ( something() && println($foo) && somethingElse() )  // does what it 
looks like, if println is a normal function
if ( something() && print($foo) && somethingElse() )  // does not print 
$foo, because the expression passed is actually ($foo)&&somethingElse()


Regards,

-- 
Rowan Tommins
[IMSoP]