Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:92787 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 78526 invoked from network); 26 Apr 2016 14:46:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Apr 2016 14:46:11 -0000 Authentication-Results: pb1.pair.com smtp.mail=bobwei9@hotmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=bobwei9@hotmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.172 as permitted sender) X-PHP-List-Original-Sender: bobwei9@hotmail.com X-Host-Fingerprint: 65.55.111.172 blu004-omc4s33.hotmail.com Received: from [65.55.111.172] ([65.55.111.172:51607] helo=BLU004-OMC4S33.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E4/32-02401-03F7F175 for ; Tue, 26 Apr 2016 10:46:11 -0400 Received: from BLU436-SMTP116 ([65.55.111.137]) by BLU004-OMC4S33.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 26 Apr 2016 07:46:05 -0700 X-TMN: [JwEwYmsR05+tAAHGBoei4Zhpw4EXeHpt] X-Originating-Email: [bobwei9@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_CE471B0C-3171-4080-B6FD-71E3539F3F72" MIME-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) In-Reply-To: <571F7B91.2030102@zend.com> Date: Tue, 26 Apr 2016 16:46:01 +0200 CC: Levi Morrison , internals , Joe Watkins References: <571F7B91.2030102@zend.com> To: Dmitry Stogov X-Mailer: Apple Mail (2.3112) X-OriginalArrivalTime: 26 Apr 2016 14:46:03.0588 (UTC) FILETIME=[5B630040:01D19FCA] Subject: Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types From: bobwei9@hotmail.com (Bob Weinand) --Apple-Mail=_CE471B0C-3171-4080-B6FD-71E3539F3F72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" > Am 26.04.2016 um 16:30 schrieb Dmitry Stogov : > On 04/26/2016 05:19 PM, Bob Weinand wrote: >>> Am 26.04.2016 um 15:33 schrieb Dmitry Stogov : >>>=20 >>> hi Levi, >>>=20 >>> It looks like your "work" on "Nullable Types" RFC was intended to = win time for this patch and block "Nullable Types" again. >>> Actually, you have been blocking it for more than a year :( >>>=20 >>> I'm going to push my own RFC for voting together with "Union Types". >>>=20 >>> https://wiki.php.net/rfc/nullable_return_types >>>=20 >>> At least, it has up to date implementation. >>>=20 >>> We discussed this internally 2-3 weeks ago, and my politeness = (or/and stupidity) allowed you to pass your version for common = discussion. >>> Now I can see your real reason :( >>>=20 >>> Both "Union Types" and "Nullable Types" may make sense, and both = should be voted at the same time. >>> Tomorrow is time to start voting. Right? >>>=20 >>> Thanks. Dmitry. >>>=20 >>>=20 >>> ________________________________________ >>> From: Levi Morrison >>> Sent: Tuesday, April 26, 2016 02:37 >>> To: internals >>> Subject: [PHP-DEV] [RFC] Patch for Union and Intersection Types >>>=20 >>> Internals, >>>=20 >>> Joe Watkins and Bob Weinand have worked out a [proof-of-concept = patch >>> for union types][1]. Please go download it and experiment with it. >>>=20 >>> A few things to note: >>>=20 >>> * This patch includes intersection types. However, a type = expression >>> must be either a union type or an intersection type; it doesn't >>> support both such as `Array | (Countable & Traversable)`. >>> * This patch adds `null`, `true` and `false` for type declarations. >>> * This patch includes conversion rules for weak types. >>> * It does not have short-hand for unions with null (`?Foo` being = `Foo | Null`) >>>=20 >>> These features (or omitted ones) are not necessarily what will be >>> voted on. Rather this patch allows us to experiment with these >>> features in code. This experience should be helpful for us to = solidify >>> how we actually feel about these features. >>>=20 >>> I especially would like people to try out the conversion rules for >>> scalar types as it has been a point of discussion. >>>=20 >>> [1]: https://github.com/php/php-src/pull/1887 >> Hey Dmitry, >>=20 >> Please, do not accuse us of blocking the nullables. This wasn't = intentional and rather a coincidence that we provided a patch right now. >> First we wanted to concentrate our forces on getting a great 7.0 out = before starting this RFC (as it didn't make it in time for going into = 7.0 too as we waited for result on scalar types in general first). >> Then, as you're aware Levi had absolutely no time for a few months=E2=80= =A6 Now, he has time to manage things and we could move ahead quickly = and write the patch up. > I know, we all like to make our best for PHP. > Sorry, if I was too emotional. Yeah, you were, but no worries ;-) >> I'd like to hold first a formal (and binding) vote on whether "null = |" or "?" should be used (in case both RFCs pass). Rushing things = through right now might just us ending up with semantics the vast = majority dislikes. > I didn't exactly get, what do you propose. One RFC with voting for = "Nullable" or "Union"? The matter is a bit complicated, as Foo | null has a bit a dependency on = unions in general. We basically need a vote on: - Regardless of unions patch, use ?Foo - If unions pass, use Foo | null - If unions fail, use ?Foo, else no nullables at all - No nullables at all (wins if more than one third of vote) For the other choices, majority wins. If we end up having two RFCs with each reaching two thirds (?Foo is a = nice concept, yes, please! and simultaneously Foo | Bar is a nice = concept, please yes!), we risk having two different RFCs implementing = the same in different ways, which may end up in a fight what should be = done. We really should clarify what exactly we vote on, before doing any = competing votes and not knowing what to do in a case where both RFCs = pass. [as the one RFC may cannibalize the other or people eventually = start voting yes on both.] Thanks, Bob > Thanks. Dmitry. >=20 >>=20 >> Thanks, >> Bob --Apple-Mail=_CE471B0C-3171-4080-B6FD-71E3539F3F72--