Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108719 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 30142 invoked from network); 22 Feb 2020 12:39:34 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 22 Feb 2020 12:39:34 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 750791804D9 for ; Sat, 22 Feb 2020 02:56:10 -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.5 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, MALFORMED_FREEMAIL,MISSING_HEADERS,RCVD_IN_DNSWL_NONE,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-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (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 ; Sat, 22 Feb 2020 02:56:09 -0800 (PST) Received: by mail-wr1-f48.google.com with SMTP id g3so4849061wrs.12 for ; Sat, 22 Feb 2020 02:56:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:cc:from:message-id; bh=Uz62NlO19P9u1v2UQ9VhSECcfc1ZpI1Qu0PbMWREibw=; b=Xlc9HOyfvXiWIt2PpDi0iwZVzN4l7SbRU/EpKww+GASAnH9JAmF93FEf6Pl6kodsVg vEcVY95TVX+LG5/rZUDrfiB9u8wq3PhhoP9bwXL0lZPtVPNCkClnioa2Rvw6qz4Lu0ym TPBxvkP3AwcOcxooBlYExqVvY+izCyg5tA3Xqrd5WaE4/bxYp+tlW8HvKnrFWSrFHMv6 rwk8vltpGmNTXQfKIBf51npl9+LIoF3YNIowqE/NTnf1MI8tlUvD4UzglylpY4ZVjYp/ k1CfqqK4gWcpESiWM7QlvtgQexyepPYxSo2KOt3mJjneI//HZG76PIxBS0mUAvv8MWgs vytA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:cc:from:message-id; bh=Uz62NlO19P9u1v2UQ9VhSECcfc1ZpI1Qu0PbMWREibw=; b=T38L1oKjfSdXbeMtdgYlgeTT6MpsDmdY5eSjDrVB0HtcI07h3mTel/qdXAGL6MGIvh K/Wj+hqqf4W8c88+4VtNcwfl5rnOSWB8VMMhKgApG1NSOunp/Oop69wwboPdKh+STMk9 VWgOxj7vXtgt7apfD4F1lnFWNkiCR0PmQGMjm0gkxFmurH4xM2dvfbaszT9J8waH49RD /0rB6Oodg5RbkIxAJV6dylMvllPKILjXejZUxBxDabJE01N1XlAl89zczbSrcs1CK03B KHm8eNab3hgPMEQolpkx7ldV9j0bMQ+G986tkMhFIFBuQwXJ9FRKaasYAGZX8muyZLXR 7+zg== X-Gm-Message-State: APjAAAVqr2y5+YcFC3jIYOJ4v9yDT9kOrio9+POoPoPjxmcFSQqZs0ZY GnPCkW3XYoyfiPnyPyG9zMZ9nqfz X-Google-Smtp-Source: APXvYqwFpZSC9+AU7W0QoggYiqAN8iwA1ve9DTDkbKLRqDzCy4NQZGC5gbEWYH72E7hSOKuz0VEvRA== X-Received: by 2002:adf:f648:: with SMTP id x8mr1129093wrp.198.1582368963139; Sat, 22 Feb 2020 02:56:03 -0800 (PST) Received: from [192.168.0.12] (cpc84253-brig22-2-0-cust114.3-3.cable.virginm.net. [81.108.141.115]) by smtp.gmail.com with ESMTPSA id d9sm8090258wrx.94.2020.02.22.02.56.02 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 22 Feb 2020 02:56:02 -0800 (PST) Date: Sat, 22 Feb 2020 10:56:00 +0000 User-Agent: K-9 Mail for Android In-Reply-To: <08159EA6-61E5-4E85-AC43-9637783315EA@newclarity.net> References: <8B2AFC37-9425-440C-B89D-61CBAAB0CDDD@gmail.com> <08159EA6-61E5-4E85-AC43-9637783315EA@newclarity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable CC: PHP internals Message-ID: <73831D4E-B53C-4350-BDAB-2F5BB31E2E8D@gmail.com> Subject: Re: [PHP-DEV] [RFC] Explicit call-site pass-by-reference (again) From: rowan.collins@gmail.com (Rowan Tommins) On 22 February 2020 06:50:46 GMT+00:00, Mike Schinkel wrote: >> On Feb 21, 2020, at 5:20 PM, Rowan Tommins >wrote: >> My instinctive reaction is still one of frustration that the pain of >removing call-site ampersands was in vain, and I will now be asked to >put most of them back in=2E > >That is a great example of what is known as a "sunken cost=2E" =20 Perhaps, yes=2E I freely admit it's an emotional reaction rather than a ra= tional one=2E >One of the reasons it is confusing is because developers are currently >required to use the ampersand in one place and not the other=2E Making >it always used removes said confusion as they would no longer be a >reason to have to remember when and when not to use the ampersand >anymore=2E Maybe=2E I think a larger part of it is that references themselves are a s= lightly confusing concept, and the fact that & looks like an operator of it= s own (and is often documented that way) but is really an annotation on oth= er operators/commands=2E That is, the & in $foo =3D &$bar and return &$bar = doesn't modify $bar, it modifies =3D and return, respectively=2E Making the rules more logical and symmetrical would perhaps be more helpfu= l to new users than it is to established users, particularly those who've k= nown multiple versions of the language already=2E > There is a potential "PR" cost of this change that should be weighed >against the advantages=2E > >To say "We fixed something that in hindsight we've since determined was >a problem=2E" How is this a concern?=20 The concern is that the costs will be much more visible to users than the = benefits, and they will resent the core developers pushing that requirement= onto them, rather than thanking then for their hard work=2E As I said, that's not an absolute reason not to do it, it's a cost to be w= eighed=2E >> I'm also not very keen on internal functions being able to do things >that can't be replicated on userland, and this RFC adds two: additional >behaviour for existing "prefer-ref" arguments, and new "prefer-value" >arguments > >So what specific problems would having these enhancement cause for the >language? There are two problems I have with internal-only features in general: the = inability to polyfill and extend, and the requirement for a separate mental= model=2E As an example of the first, the RFC mentions using call_user_func with a c= all-site annotation to forward the parameter by reference=2E The reason for= allowing that also applies to a user-defined wrapper like call_with_curren= t_user or call_with_swapped_parameters, but there's no syntax for those to = be marked "prefer-val"=2E 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=2E To those without knowledge of the core, those functions = simply have to be remembered as "magic", because their behaviour can't be m= odelled as part of the normal language=2E >> My current opinion is that I'd rather wait for the details of out and >inout parameters to be worked out, and reap higher gains for the same >cost=2E For instance, if preg_match could mark $matches as "out", I'd be >more happy to run in a mode where I needed to add a call-site keyword=2E > >This sounds like preferring perfect in the (potentially distant) future >vs=2E much better today=2E No, it's preferring to hold out for a little bit more value to weigh again= st my evaluation of the cost=2E=20 This is, when followed through to its conclusion of mandatory marking, a d= isruptive change to every piece of code, so we need to decide if the disrup= tion is worth it=2E=20 It's also the second change in the same place, and we should be sure that = we've got it right this time, and won't require a third change in the near = future=2E For instance, if out parameters were added, would the same line o= f code end up going from optional &, to forbidden &, to mandatory &, to man= datory "out"?=20 I'm not strongly against the idea, but the advantages just don't feel quit= e strong enough, so if I had a vote, I'd currently be inclined to vote no= =2E Regards, --=20 Rowan Tommins [IMSoP]