Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108747 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 26331 invoked from network); 25 Feb 2020 00:15:14 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 25 Feb 2020 00:15:14 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C06E2180089 for ; Mon, 24 Feb 2020 14:32:28 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-qt1-f196.google.com (mail-qt1-f196.google.com [209.85.160.196]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 24 Feb 2020 14:32:28 -0800 (PST) Received: by mail-qt1-f196.google.com with SMTP id l21so7709716qtr.8 for ; Mon, 24 Feb 2020 14:32:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PPghaZQcxGsAf/Dj6liOOFAWmJmjR+F1JM4jv7oyzsE=; b=qIGy6jr5lMVFxEZXGg0PWC4GmMtxOYTIVNLd+xmSjBhUaRjJmEKf5NI8EvwLSvsWPe Dxh4iwWXHPSBlgjrzrVU7rXmOGHJ/k9z+mmwdlSS1MiD6e2ir66BOOjheiLge/DOcS4d +R2vNNAky+gHWat6HE9uHQENX6I2IH4ALviaCO718LmM81qEmmdTjpTUUd9FZYrQ/vaw 9klYNQj2Tmh81AaA7BHB84tUqkZGSwLfbN+VJFEm1vKZjk+aquhqpCa++r5JiNU4GSOt s4IfS6EXFYq9zQq/TPSYA9luIhdJbaD5qJw8n0Kx/T/iqOtowtMZcZn48Lc6ZUw+fozx G6/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PPghaZQcxGsAf/Dj6liOOFAWmJmjR+F1JM4jv7oyzsE=; b=rKDhI+SdtaHOGn5E62JgtaNdTFfn3HD32hNk1R4WN+ujaIhD2TGAn/R5OqdzRqsqpA i9HptWhhCdJ3bVZMfYJkBrSdcLtMAahc6rDpABfLg4jXzpIijMIyVOSuYbUba0xFcHjT SEIw4JPBjL4lICZ+DWRQONWuU73HRSnmlfU9exnaX4RgXjtyUzyjUye1EryDYL+OW6Y0 U6+ffZebHDteiiK3wP30KpjvX9dYS0lAVlmcIO0BYxxuvpUCrVoreohR39ypbN4GY5+2 3ezOJtQQc9R2KnzGKAeqIld6MaQocI8uyP3sPmgwsxRuBWCrT7I67LbFZzoN3UVzgW5e 8P3Q== X-Gm-Message-State: APjAAAVSFbTbC1qodFy6138ki6JTF1tBitGRBeJA9P9DDtbJ/IrLKRqD /dmlxFw6WjiivHBIhGAZAo6+9w== X-Google-Smtp-Source: APXvYqzF/7JptDzAHKOioisfZ+H5ovOV5iKiDPYG4DGsdOvIh3ot1eUyoPpKzJa271FmP/E5J7LW1w== X-Received: by 2002:aed:2321:: with SMTP id h30mr51084151qtc.355.1582583541454; Mon, 24 Feb 2020 14:32:21 -0800 (PST) Received: from [192.168.1.10] (c-24-131-44-78.hsd1.ga.comcast.net. [24.131.44.78]) by smtp.gmail.com with ESMTPSA id j30sm6419560qki.96.2020.02.24.14.32.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Feb 2020 14:32:20 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) In-Reply-To: Date: Mon, 24 Feb 2020 17:32:18 -0500 Cc: PHP internals Content-Transfer-Encoding: quoted-printable Message-ID: <5725BD0A-321C-4DCC-A9F7-1A30B80103A5@newclarity.net> References: <8B2AFC37-9425-440C-B89D-61CBAAB0CDDD@gmail.com> <08159EA6-61E5-4E85-AC43-9637783315EA@newclarity.net> <73831D4E-B53C-4350-BDAB-2F5BB31E2E8D@gmail.com> <03009039-9B2B-49BC-9CFF-CFB77BEFE2DC@newclarity.net> To: Rowan Tommins X-Mailer: Apple Mail (2.3445.104.11) Subject: Re: [PHP-DEV] [RFC] Explicit call-site pass-by-reference (again) From: mike@newclarity.net (Mike Schinkel) > On Feb 23, 2020, at 9:23 AM, Rowan Tommins = wrote: >=20 > Hi Mike, >=20 > First, I'd just like to reiterate that I absolutely see benefits in = this proposal, and am definitely not campaigning for it to be abandoned = as a bad idea. Like with any proposal, we have to weigh those benefits = against the costs, and my current personal opinion is that the scales = come down *very slightly* on the cost side. >=20 > I will also just say that you have made some valid points about = different ways people might perceive this change, and my fears on that = score may be overblown. >=20 >=20 > On 23/02/2020 07:03, Mike Schinkel wrote: >=20 >> The RFC does not require mandatory use, period. >>=20 >> The "cost" you worry about will not exist unless and until a future = RFC proposes to make it mandatory and that RFC is accepted. >=20 > The RFC states very clearly that the full benefit of the change will = only be realised by making the markers mandatory in some way, and = includes specific discussion of how that might be introduced. Put = simply, tools (and even humans) get most from knowing that a particular = line of code *won't* pass anything by reference, and optional markers = can't guarantee that. Fair point. >=20 > I am analysing the proposal on that basis, just as I would analyse a = proposed deprecation on the basis that the deprecated feature will one = day be removed. >=20 > If we analyse it on the basis of it *never* becoming mandatory, we = have to adjust our analysis of both costs *and* benefits. However, if you consider editions, it may not ever need to become = mandatory and yet those who want it could still benefit. > Regarding prefer-ref and prefer-val: >=20 >> function call_with_current_user(Callable $callable, int &$foo, int = $bar ) { >> return call_user_func( $callable, current_user(), &$foo, $bar ); >> } >=20 >=20 > If you define the function this way, all callers are *required* to = pass the parameter by reference. That immediately means that this is a = fatal error: >=20 > call_with_current_user('foobar', 42, 42); >=20 > Internal functions have the magical ability to accept both literals = values and reference variables, whereas userland functions have to = choose one or the other. Uh, yeah I guess. But I would ask the question, why would you want to do = that? The reason we don't make the ampersand a requirement is a legacy = concern. But if you are writing a new function there is no legacy = concern. So it would seem a developer would *want* to force the = ampersand.=20 Or is your point just that there are a list of possible options and you = want the ability to use _all_ options from that list regardless of = whether a specific option has a valid use-case? >>> As an example of the second, even under strict settings, calls to = certain internal functions will have an optional & at the call site, = which changes their behaviour. >>>=20 >>> To those without knowledge of the core, those functions simply have = to be remembered as "magic", because their behaviour can't be modelled = as part of the normal language. >> I am unclear how the optional ampersand at the call site will change = the behavior. >=20 >=20 > I was referring to this line in the RFC: >=20 >> If the argument is a prefer-ref argument of an internal function, = then adding the |&| annotation will pass it by reference, while not = adding it will pass it by value. Outside this mode, the passing behavior = would instead be determined by the VM kind of the argument operand.=20 >=20 >=20 > That means that for any function implemented internally as = "prefer-ref", the user can now *choose* whether their variable will be = overwritten by the function. I don't know exactly which functions this = would affect, because as far as I know, the manual doesn't have a = standard way to annotate "prefer-ref". Which is kind of my point: it's = magic behaviour which sits outside most people's understanding of the = language. Sounds like the solution then is to update the documentation? > I don't particularly see a problem with requiring a third change in = the future. Hindsight is a wonderful clarifier. And I believe elsewhere = you have been debating me over the need for incremental change. Caveat = emptor.=20 >=20 >=20 > The distinction I would make is between incremental change, and = contradictory change. If we later introduce out parameters in a way = that's compatible with call-site &, that would indeed be incremental = change; the effort spent adding & would move code closer to the final = state. If we end up introducing call-site "out", the effort spent adding = & will simply be compounded with the effort spent adding "out". > Predicting the future is a mug's game, but it's at least worth = exploring some possible futures, and how decisions now might help or = hinder them. I do agree that changes that are contradictory as problematic. However, in this case Nikita has weighed in and said "out" is unlikely = to happen. So that seems to remove the concern about conflicts with out = parameters? -Mike=