Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107320 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 94204 invoked from network); 26 Sep 2019 02:38:13 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 26 Sep 2019 02:38:13 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 356EF2D19B6 for ; Wed, 25 Sep 2019 17:17:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS11403 64.147.123.0/24 X-Spam-Virus: No Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Wed, 25 Sep 2019 17:17:28 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 8265E5BB for ; Wed, 25 Sep 2019 20:17:27 -0400 (EDT) Received: from imap26 ([10.202.2.76]) by compute7.internal (MEProxy); Wed, 25 Sep 2019 20:17:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=o7cCjN DdEYeQXyQMia9/OBWNZO0lXYbJDNi4EVWeUZY=; b=LnKClDcEb4eAGTm/hgDkOH i/zZRr79T6qbeZPrCLqrfPXO7HMToQ1SrrTR39gPRC3mJqnrIww3nTIgTM5nEtcu GH3zPVKQo5o2c0UPMLKdqszCzrtw5N3Xfpbpr/DIC2WWz3Xs745f4udbMFC1po2Z qB+GuIItP6ossuLnIMo0PyiHO9zyr6M70htMZzlU6EyRh+OZQ6APGtgA+c6XkMPz 2/Leok2O6BKWcaQu9wqYj65t3JRvzZH/gQKNTAUtZmvjAJuClF7zaIfoxx0v+NfM zPYM4f3jlBVmKdQ/xQBTvs4wSQpwjGwFkiXFMjsYeuWOn0wNJgR7+9tFPT0cAx1Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrfeefgdefudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfnfgrrhhr hicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh eqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehlrghrrhihsehgrghrfhhivghlughtvggt hhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9BBB014200A1; Wed, 25 Sep 2019 20:17:26 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-305-g4111847-fmstable-20190924v1 Mime-Version: 1.0 Message-ID: In-Reply-To: References: <1544E25D-630F-4E02-BCF1-1A0DEF1EBD60@gmail.com> Date: Wed, 25 Sep 2019 19:17:03 -0500 To: "php internals" Content-Type: text/plain X-Envelope-From: Subject: Re: [PHP-DEV] [RFC] Union Types v2 From: larry@garfieldtech.com ("Larry Garfield") On Tue, Sep 24, 2019, at 3:05 PM, Sara Golemon wrote: > On Tue, Sep 24, 2019 at 12:24 PM Claude Pache > wrote: > > The choice of supporting precisely the two literal values `null` and > `false` > > is not arbitrary: They are the two values that are the most often used as > > sentinel values (for indicating failure or absence). It is true that > `true` is > > also sometimes used as sentinel value (more rarely and not among the > > internal functions), but the same can be said of other literal values > > (one of your examples includes `0`). > > > While I personally think `false` makes sense as an allowed "type", I also > don't want to see the union types RFC get held up on such a tiny detail. > > I would propose either of the following alternatives: > 1/ Remove `false` from the proposal. It can always be added at a later > time, but not taken away. > 2/ Make this detail a sub-vote. I would suggest that this sub-vote should > also be subject to a 2/3 majority in order to pass. > > -Sara I would tend to agree with Sara. That seems to be the only issue of contention and it is (AFAIK) reasonably straightforward to add "later" without blocking the rest of Union types. It would mean some functions wouldn't be able to get a fully accurate return type yet but... they've survived this long without them, they can wait a bit longer while this gets settled and/or some even more robust alternative is found. --Larry Garfield