> Am 26.04.2016 um 16:30 schrieb Dmitry Stogov <dmi...@zend.com>: > On 04/26/2016 05:19 PM, Bob Weinand wrote: >>> Am 26.04.2016 um 15:33 schrieb Dmitry Stogov <dmi...@zend.com>: >>> >>> hi Levi, >>> >>> 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 :( >>> >>> I'm going to push my own RFC for voting together with "Union Types". >>> >>> https://wiki.php.net/rfc/nullable_return_types >>> >>> At least, it has up to date implementation. >>> >>> 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 :( >>> >>> 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? >>> >>> Thanks. Dmitry. >>> >>> >>> ________________________________________ >>> From: Levi Morrison <morrison.l...@gmail.com> >>> Sent: Tuesday, April 26, 2016 02:37 >>> To: internals >>> Subject: [PHP-DEV] [RFC] Patch for Union and Intersection Types >>> >>> Internals, >>> >>> 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. >>> >>> A few things to note: >>> >>> * 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`) >>> >>> 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. >>> >>> I especially would like people to try out the conversion rules for >>> scalar types as it has been a point of discussion. >>> >>> [1]: https://github.com/php/php-src/pull/1887 >> Hey Dmitry, >> >> 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… 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. > >> >> Thanks, >> Bob
