Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101267
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain rhsoft.net designates 91.118.73.15 as permitted sender)
To: internals@lists.php.net
References: <CAF+90c87_Zd07ftVe29=GdjxhxjkFG+VXfm_ZZ3QWqER50QLuA@mail.gmail.com>
 <91639df6-4fbd-a649-6558-7ae9130020ff@telia.com>
 <c6247963-52a7-6532-676b-3f06a5c740e0@rhsoft.net>
 <670DE052-934C-4EFE-9B70-C59736EAFAD1@koalephant.com>
Message-ID: <2dd0e62d-1885-08d3-2ca5-4f6c3c68176f@rhsoft.net>
Date: Fri, 8 Dec 2017 11:16:01 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <670DE052-934C-4EFE-9B70-C59736EAFAD1@koalephant.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: de-CH
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax
From: lists@rhsoft.net ("lists@rhsoft.net")



Am 08.12.2017 um 05:41 schrieb Stephen Reay:
> 
> 
>> On 8 Dec 2017, at 08:54, "lists@rhsoft.net" <lists@rhsoft.net> wrote:
>>
>>
>>
>>> Am 08.12.2017 um 01:38 schrieb Björn Larsson:
>>>> Den 2017-12-06 kl. 20:49, skrev Nikita Popov:
>>>> Hi internals,
>>>>
>>>> I'd like propose optional support for explicitly marking by-reference
>>>> argument passing at the call-site, in addition to the declaration-site:
>>>>
>>>>       https://wiki.php.net/rfc/explicit_send_by_ref
>>>>
>>>> In short, while currently we have
>>>>
>>>>       function byRef(&$ref) {...}
>>>>       byRef($var);
>>>>
>>>> this proposal would also allow
>>>>
>>>>       function byRef(&$ref) {...}
>>>>       byRef(&$var);
>>>>
>>>> so that the use of by-reference passing is obvious without having to
>>>> consult the function declaration.
>>>>
>>> I think this proposal has a good point about static analysers,
>>> not just about human readability.
>>> A good static analyser is very helpful for eg migration projects
>>> and if this proposal benefits that, it's a plus. Also using same
>>> syntax for references like in other parts of the language has a
>>> value.
>>> Now expressing the same thing in two different ways, with or
>>> without & is confusing, so I think one needs to think about if
>>> old syntax should be deprecated in 8.0
>>
>> to get this consistent that would also require change every line of code calling core functions like sort instead of sort($array) as sort($array)
>>
>> i doubt that the benefits could justify the BC break
> I think Rowan's suggestion makes a lot of sense. There's zero bc break for existing code, but new/updated code can get the benefits of being specific about how the parameter is used.

"Now expressing the same thing in two different ways, with or without & 
is confusing, so I think one needs to think about if old syntax should 
be deprecated in 8.0" would be a massive BC break

and it's much bader to use a not so long existed syntax which was now 
changed to a fatal error - just type "php call-by-reference" in google

> I know "references are the wrong tool for any job" is a belief held my some of the community - I'm curious if out/inout parameters solve any of their concerns about references?

now because they are not bad because the syntax, they are bad fopr most 
usecases because you try to be smarter the PHP's copy-on-write but in 
most cases you won't