Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103599 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 22315 invoked from network); 12 Dec 2018 20:01:17 -0000 Received: from unknown (HELO mail-lj1-f175.google.com) (209.85.208.175) by pb1.pair.com with SMTP; 12 Dec 2018 20:01:17 -0000 Received: by mail-lj1-f175.google.com with SMTP id t9-v6so16820742ljh.6 for ; Wed, 12 Dec 2018 08:28:42 -0800 (PST) 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:cc:content-transfer-encoding; bh=YfYUOqn90fqJj/Q6q0MXAMUqQcx8tynhgWMAMMbyrNI=; b=TSGAs85lPhouv5PHgjVlGD43il+CQEu/M1q8+ndp1lH4FN7v8An0m9jeE98XGeOgyM maoh/NJUoIYkKByvI/bdJT3NG0VMBfQpjguwN7kKbaNhYemvZB94R1lHb2JiT6LTvcT0 5rsUNMKzljjBiD96N0IMoqYIs40jqDEze+KA9XGB+TH9yjp3rxC/3EIZGQ+jq5t8Tl8E bXpGA2Z0MKXZ/tDIL5Mu7uTDzR3+WNeWON0DjfL7w/k6GZgCG6FgghTUFCyFdLhnhjwZ QvBR/gRzHsy+oQBqt0WqggvZfqeZHh9yhH2Qxxc2IDK6R5YXBhahwS3mUq6BpQfRM1Uz tVvQ== X-Gm-Message-State: AA+aEWYBmlQ3sEIAn8uIFZ2pd7YAYWJ1cxLfHGJL6SrjPspX1bWY6P+J eoQgB82zn4M8Ffz0y3cgGCTFPJIKRcfV0/lm9yg= X-Google-Smtp-Source: AFSGD/UtnL4NkCphMEt9Gu40yImB0JbnchkucXVg2/waez16gZlFHhhY68xo0a3jxaLtXdKd4VEUTjmyo/7onxJrGxE= X-Received: by 2002:a2e:2b11:: with SMTP id q17-v6mr12489199lje.25.1544632121165; Wed, 12 Dec 2018 08:28:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 12 Dec 2018 09:28:24 -0700 Message-ID: To: Christoph Becker Cc: internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [RFC][Discuss] Covariant return- and contravariant parameter- types From: levim@php.net (Levi Morrison) On Wed, Dec 12, 2018 at 4:25 AM Christoph M. Becker wro= te: > > On 11.12.2018 at 21:34, Levi Morrison wrote: > > > On Mon, Nov 26, 2018 at 2:25 PM Levi Morrison wrote: > > > >> I am happy to announce my latest RFC, [Covariant Returns and > >> Contravariant Parameters][1], is open for discussion. If you do not > >> recognize those terms then hopefully the introduction coupled with the > >> [examples][2] will help. [=E2=80=A6] > >> > >> [1]: https://wiki.php.net/rfc/covariant-returns-and-contravariant-pa= rameters > >> [2]: https://wiki.php.net/rfc/covariant-returns-and-contravariant-pa= rameters#examples > > > > It has been two weeks now. If you want to provide any feedback, or > > follow-up on anything from the discussion, please do so soon. I hope > > to put this to vote before the end of the year. > > Thanks for working on this, Levi. Highly appreciated! > > I may have missed this, but otherwise I'd be quite surprised that nobody > had commented on: > > | Therefore, by-reference parameters are still contravariant, [=E2=80=A6] > > Call-by-reference is not seldom used to provide out-parameters, but > these should not be contravariant according to LSP. Therefore, it might > be best to keep by-reference parameters invariant. > > -- > Christoph M. Becker Christoph, we cannot make any guarantees about the type of the variable when the function returns because the type of the parameter is only checked on function entry, and not also on function exit, e.g. function array_baz(array &$in) { $in =3D 1; } $array =3D []; array_baz($array); // valid var_export($array); // 1 I do think we ought to have "out" parameters some day which would prevent this behavior (as well as have some other benefits), but that is out of scope for this RFC. The RFC notes that if we had "inout" parameters that they would need to be invariant. It also says that "out" parameters would be invariant, but they may be covariant depending on the exact semantics specified -- all that can be handled in the RFC that proposes it. I will add this example (or maybe a better one) to the RFC. Thanks for bringing it up.