Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108730 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 69228 invoked from network); 23 Feb 2020 16:24:26 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 23 Feb 2020 16:24:26 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B83431804A7 for ; Sun, 23 Feb 2020 06:41:21 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS 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-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 ; Sun, 23 Feb 2020 06:41:21 -0800 (PST) Received: by mail-wm1-f45.google.com with SMTP id p9so6488872wmc.2 for ; Sun, 23 Feb 2020 06:41:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=D5Xj4vgJOKs7shmMotofI1QNlcsbH0cO6w4Oh9+sB+s=; b=lsFttxKTNV4657ziDsANFvM1M8LGkP/rxip5ougyn1CRTu7ebgoUbvAnRZidPv5B// EgO70L5dT7UWFFWiExfRScqnMXaxb9GDVDXKg6dSVgGesPpsHjOGm9r5kjavoCJ3iEGK 1Nuj0n/OB0BVMqVVd3XMiD6G0QmSLyZanPH5NZbMWIxBYsCVx7Ux3XNJ4iWHAFlMyjWw Sifxhkl6h0uis5DohIl5UVCBbbWXOQvmxBPZmpvFpTcnXdiVVtYKDJfYk3axKXSZfsjk bi2b2bYGoZ8XGJIs2UFkyFq78Z94isok23dZI2Ej9EhDpQiFXGkrd/fwTgFWNVVLD61Y DlNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=D5Xj4vgJOKs7shmMotofI1QNlcsbH0cO6w4Oh9+sB+s=; b=gtCsb/XQC0/jSos+jzasdObiviRJ3YtnVh7wgIglQq774RA2Phe3Obbc+iG+w+Pmym 6EiVgPRkNNViRjYSXgQpo/iyFiuJZJ97fR3HW8PXNtH8nZPQ4rz/p87ZAx2O+rwOtynV sQ1BMgjvmRqEQR8tDDf938nrptaFq4JayHbTKfV/tjN5YmLzoQVXGBZBNjkHSgMbCk6x iTKdNlmqE/B6My8Uw5Nb4ZG0FHDqzfhLMfiuI+pms0qgXdW04H/ukTKUmOqtqx78poUv +CDwIkNtKjNUcyf7idlBZyIEeMbHEOnhyL8STF9lXcruMyUE4S3rgEYv0Vbrq6kPFiPe yBEg== X-Gm-Message-State: APjAAAVX1o5HozJ521nRymtEteZ7oz4JiQrK0fWMErBvhznqeqMU0kNq APyrp1wexkoR6T2IlxjrpvJ4UGNu X-Google-Smtp-Source: APXvYqxHVydLencVaQxvkjb/LG5NWJbbaQXxdvW/fK8bBt6/1twQhgsCFKOLUY7LkkkyNy0HcOJHCA== X-Received: by 2002:a1c:610a:: with SMTP id v10mr9542435wmb.44.1582468876718; Sun, 23 Feb 2020 06:41:16 -0800 (PST) Received: from [192.168.0.14] (cpc84253-brig22-2-0-cust114.3-3.cable.virginm.net. [81.108.141.115]) by smtp.googlemail.com with ESMTPSA id c77sm13878827wmd.12.2020.02.23.06.41.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 23 Feb 2020 06:41:16 -0800 (PST) To: PHP internals References: <8B2AFC37-9425-440C-B89D-61CBAAB0CDDD@gmail.com> Message-ID: Date: Sun, 23 Feb 2020 14:41:14 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Subject: Re: [PHP-DEV] [RFC] Explicit call-site pass-by-reference (again) From: rowan.collins@gmail.com (Rowan Tommins) On 23/02/2020 09:47, Nikita Popov wrote: > The prefer-ref/prefer-val thing is indeed a bit peculiar. It's an > artifact of the current way of implicit by-reference passing, where > the decision of whether to pass by-value or by-reference has to be > made based on an "educated guess" at the call-site. That leaves us > with always-val, always-ref, prefer-val and prefer-ref as the possible > passing modes. In the explicit by-ref passing regime, the latter two > consolidate, and we have by-val, by-ref and "either" as the options, > which is a lot more obvious. Thanks, that's a good summary of how this all relates to the RFC. If there is a use case for such a mode, perhaps we need a way to annotate userland functions as "either", so that they too can take advantage of the call-site annotation. In a sense, they'd be opting in to the pre-5.4 behaviour, for that particular parameter. > Instead of having __call(), what we really should have is __get_method(). That is a really interesting idea. The lack of function signature is currently a big turn-off for using __call, because it means manually recreating a lot of the unpacking and type checking that the language would normally do for you. > I believe we talked about this in some detail in the previous > discussion on this topic. My basic stance on in/out is that it's > *probably* not worth the complexity, unless it is part of an effort to > eliminate references from PHP entirely (which would be hugely > beneficial). Unfortunately I don't really see a clear pathway towards > that. "out" parameters can remove one use-case of references, and I > can see how that would work both in terms of semantics and > implementation. The case of "inout" parameters is much more > problematic. While these can nominally work without references, I > don't see how they could do so efficiently (we would have to "move > out" the value from the original location to avoid COW). Similarly, I > don't have any answer to how &__get() and &offsetGet() would work > without references. That's fair enough. I guess the reason I've fixated on them is that I'd really like "out" parameters, independent of what else happens with references, in order to get the clear signal of "variable is initialised here" on a call like "preg_match($foo, $bar, out $matches)". That would make out parameters more attractive to build APIs around, e.g. when you want multiple strongly typed outputs from one call. Even if we can't eliminate references entirely, perhaps there's value in reducing the use cases where they're necessary? A bit like how property accessor syntax wouldn't allow us to remove __get and __set, but would mean fewer cases where people needed to deal with them. Regards, -- Rowan Tommins (né Collins) [IMSoP]