Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:101259 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 49557 invoked from network); 6 Dec 2017 21:41:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Dec 2017 21:41:44 -0000 Authentication-Results: pb1.pair.com smtp.mail=dave@mudsite.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=dave+php@mudsite.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain mudsite.com designates 209.85.217.176 as permitted sender) X-PHP-List-Original-Sender: dave@mudsite.com X-Host-Fingerprint: 209.85.217.176 mail-ua0-f176.google.com Received: from [209.85.217.176] ([209.85.217.176:43653] helo=mail-ua0-f176.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7D/94-24804-614682A5 for ; Wed, 06 Dec 2017 16:41:43 -0500 Received: by mail-ua0-f176.google.com with SMTP id e10so3897618uah.10 for ; Wed, 06 Dec 2017 13:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mudsite-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=YWQUHoIZ6Yb/3Wwx10Vln+T53fILY8LAv/3mb4zJdtA=; b=0Vrl0RO6Ac3lOOooNhL+V8FOJuqVrzcA9hSbIfKi45kajvdxhK3d1rG1f7gYHZ8/NX aa7qRMDGtks70th2CIOwJzowTwwY3bodgw/JWOvL5n2PARR41LDujiHPzmBv6QOwIztM iULrNm64T0HhBrSwEQwuN4rhPlHqYgJC1M8nwYgZDsLStgsSdfmdNJnhLRdFRydxoH6w XW9oS3bjN+WxOK4VLBiKnOpnG95iQIiPpl6Rtwy+s94oqhJk8OIyeydus7ldOZnW6sZV U/iyjoHexOlbTnCiojoD1ewuChQlmW30dktIanoaomtW0djTyuCqfixEya8aUevcwO6i PAIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=YWQUHoIZ6Yb/3Wwx10Vln+T53fILY8LAv/3mb4zJdtA=; b=p/Jxf6olBPU8udumnT0xMcg3VwYLezUDnHuVIt6mHRbqy+qKTicwMZkePKhG4lIv1U J6F/uW0loCEz9fRbJflNCTRvsUwMwWdjYixwA/q7nVCQENNlIMg0vp6lEkviD3RpQDjE 6cdoXs1BrfDrtJGmsjfTVoLfwn1j+Z0k1exX4nlA7VaOo9nfFDsk/tO6w6CXYM2g37BQ pTd0ly5FlZoYTjJB9F2wY4ehKwEDdE/X1bYQ5f34tO9awvK5ACqEBC4Y9p/wD97hWqlf CDJSoK5Xzg+CKymIcEvVDb42Vx1wEJ/ICXKUxFZehMZXzzXyulanE1pIF/cI96YRdbki uCjg== X-Gm-Message-State: AKGB3mIiNGZTBBtaqxl04CLARhw3xvXkcDBCJYe7cS0kp1efl1LaTUr1 rrDctJqRbcB7kl0oAVjzdQmhk2IpR7JOAfqaHMI5Zg== X-Google-Smtp-Source: AGs4zMZoOWO8JBbYkp8iDnQOdejKBLzwtvdQMEbNXDD56e+styLCiz3DIizAMxdBotTJ6I+ygoZNfS3tLg4QoAKw9I8= X-Received: by 10.176.67.71 with SMTP id k65mr11470815uak.59.1512596499081; Wed, 06 Dec 2017 13:41:39 -0800 (PST) MIME-Version: 1.0 References: <2d16694d-d9d7-77b1-6a9d-740b92750878@gmail.com> In-Reply-To: <2d16694d-d9d7-77b1-6a9d-740b92750878@gmail.com> Date: Wed, 06 Dec 2017 21:41:28 +0000 Message-ID: To: internals@lists.php.net Content-Type: multipart/alternative; boundary="001a114fc04e044b91055fb2d1d4" Subject: Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax From: dave+php@mudsite.com (David Walker) --001a114fc04e044b91055fb2d1d4 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 6, 2017 at 2:32 PM Rowan Collins wrote: > On 06/12/2017 19:49, Nikita Popov wrote: > > 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 > > > Hi Nikita, > > I approve of the aims of this proposal, but I do wonder if it would be a > bit awkward to reuse the syntax which people had to spend so much effort > removing in PHP 5.4 (you refer to it as a PHP 4 feature, but for many > people it's a much more recent memory). Aside from the frustration of > "why didn't we allow it in these cases all along", I can see people > being confused if it went from OK to fatal error to encouraged and maybe > even mandatory. > > Your future scope section mentions having more explicit "out" and > "inout" annotations; perhaps it would be better to skip ahead to these, > with new syntax, and more immediate benefits all round. Is there a > reason we can't do this right now? > > I imagine these working like the & annotation, with the following extra > rules: > > 1) Parameters marked "out" or "inout" in function definitions MUST also > be marked "out" or "inout" in calls to that function. > 2) Parameters marked "&" in function definitions MAY be marked with > "out" or "inout" in calls to that function. > 3) A variable passed to an "inout" parameter would raise a notice if it > was not defined before use, since it should have a value for the "in" part. > 4) A variable passed to an "out" parameter would NOT raise such a > notice, since the function call would be a valid initialisation. > 5) An already-initialised variable passed to an "out" parameter would be > set to null before calling the function. If the function never assigned > to it, it would remain null in the calling scope. > > Rule 2 allows for better interoperability between old and new code, and > I am imagining it also applying to core functions, so that this would > work without pre-initialising $matches: preg_match($pattern, $string, > out $matches); > > I'm not sure how reference-returning functions fit into this picture, > and there are probably other kinks to iron out, but it seems like it > would have a lot more benefits overall. > > Regards, Hi Nikita, I'd be more hesitant about seeing this syntax re-introdouced. Having recently been through the process of spending days to remove all the call-time by-reference fatals. Especially when the syntax proposed is generally ignored (excepting in the has &, but declaration doesn't). I do like the C-esque feel of having the declaration require a reference, and the call-side provide the reference, but the RFC lacks the warning where the declaration has reference, but call-side lacks it. However, adding this warning would probably anger everyone who did spend the time to remove all the call-time references only to now add them back in. I'd be with Rowan here. If the language is going to re-introduce old syntax as purely a visual aid, it would probably behoove us to actually look at the in/inout/out parameter types. I would be way more excited to see that play out, than having call-time-reference brought back. Cheers, -- Dave --001a114fc04e044b91055fb2d1d4--