Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118718 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 78417 invoked from network); 30 Sep 2022 15:17:10 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 30 Sep 2022 15:17:10 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 096EB1804AB for ; Fri, 30 Sep 2022 08:17:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS29838 64.147.123.0/24 X-Spam-Virus: No X-Envelope-From: Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 30 Sep 2022 08:17:06 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 1877232009E4 for ; Fri, 30 Sep 2022 11:17:02 -0400 (EDT) Received: from imap50 ([10.202.2.100]) by compute1.internal (MEProxy); Fri, 30 Sep 2022 11:17:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= garfieldtech.com; h=cc:content-transfer-encoding:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to; s=fm2; t=1664551021; x=1664637421; bh=h7KTLNhJQPWh0ONbuTm+Kxu2R X23LxLKlALlIwXXJXM=; b=cUqthjgxjGRlOXR902H+fWLZb4TjRcuRduMbfl8wT EZOXUC9t99mufmLFUk8E7LnfgaWENKyK9DtDNmDCrTqwMqCCj5iYLntgQ72WEl4g afVPHuHAaNX7gNVHoGo0HGSSsAbFM/HwfLSqUjTUqQ3H/hVYXpuZzmBv+U9IL0Hg /a+QA3w3sWh08GporKW/631wyw9WojTnsXaPgwWPFnSB2F3w4yV0JEmzB7KCOF5z mOZ2q82YCUKJynLqjKzIZVWZJ0mmxPp82ZiuW6ZrIg2TA6TQoAk8OpaJZnDdRJzR +Ptv6R9HsK9Q7wCZpval0NGJt1bt/XW2h1mudI9hkrvwg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1664551021; x=1664637421; bh=h 7KTLNhJQPWh0ONbuTm+Kxu2RX23LxLKlALlIwXXJXM=; b=jxhWDINzPdLyffZKe G3knNriT2fTA/K3W4JyoSPh47IrpPXAtCin4PpctVsPjScP486DRCfhJMRZXfRDQ qrlbMQL8bgWna+3KsCQxR10zfC82864pdqhMA5Ema7Gps4Xtxh0oKYpUtGyKshZ6 lgKn+4NOR8rYznWTONPz9xSKJQQBoAcFqNE6cXuqaFyWqzD/GBbEOtmjkwlwGuZ7 66sbiqqDj5xuMuo+Vt6HZETZj4U+XfiYDqm5HbdEVYde0BowHH08Za0rjvdU5TBF OeRrLJBsriRdoIAk0nLQLv9BtvbflzfQqGGfzL4CM5Qp7EIXAqhqc+fA38m2KdZa PDTGQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeehvddgkeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfnfgr rhhrhicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtg homheqnecuggftrfgrthhtvghrnhepffffffejffdugfegvedviedttedvgfejffefffej leefjeetveehgefhhfdvgfelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomheplhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtohhm X-ME-Proxy: Feedback-ID: i8414410d:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6708A1700086; Fri, 30 Sep 2022 11:17:01 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-968-g04df58079d-fm-20220921.001-g04df5807 Mime-Version: 1.0 Message-ID: <38350298-6aaa-4739-b927-0a9423baae4e@app.fastmail.com> In-Reply-To: References: Date: Fri, 30 Sep 2022 10:16:39 -0500 To: "php internals" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Re: Alias for `int|float` From: larry@garfieldtech.com ("Larry Garfield") On Fri, Sep 30, 2022, at 4:04 AM, Olle H=C3=A4rstedt wrote: > 2022-09-29 5:08 GMT+02:00, Hamza Ahmad : >> Hi Olle, >> >> I appreciate your idea of introducing a similar concept of typedef. >> What if you write an RFC explaining that concept. I can join you >> however in co-authoring this request. >> >> Seriously, I have had issues with writing such type again and again. >> If you look at mixed type, it is indeed an alias of some union types. >> Adding such an option to userland would lead to introduction of >> various type hints. Plus, it will help devs write short hand aliases >> for their intersection types. > > Note that my suggestion here is NOT about a project-global type alias, > but an extension of the existing file-only alias, the use-statement. > This can also explain the lack of reaction. :) Internal devs might > already have consensus on the right way to proceed here, even if > there's no RFC yet. Background: Type aliases have been discussed several times. There's definitely inte= rest, but like many things it runs into the problems of time and figurin= g out the details. In particular, I don't get the sense that there's much appetite for file= -local aliases. While that would have some benefit, it could lead to al= l kinds of confusion when then using code from another file. Consider: A.php: use int|float as number; interface A { public function a(number $a) {} } B.php: // Yeah, aliasing this is very helpful. use (Request&Linkable)|(ServerRequest&Linkable)|array|null as input; interface B { public function b(input $b) {} } C.php: class C implements A, B { // Which of these to use? public function a(int|float $a) {} public function a(number $a) {} // Or do I need to repeat the definition of "number" in every file? // WTF do I do here? Do I have to repeat the entire definition either // inline or in this file's "use" block? Both suck. public function b(...) } This becomes even more of an issue when you start talking about function= types, which is often mentioned as the primary use case. =20 type fn(int $a, string $b): Request as mycallback function do(mycallback $callback) {} So I have to duplicate the type def in every file now? This is not an i= mprovement. So we have to go with app-global aliases, but then... how do you handle = resolution? Autoloading? Namespacing? Conflict resolution? I dunno, = that's all hard, and that's where the conversation usually peters out. The degenerate case you mention of simple type renaming has its own inte= resting implications, which are also a factor for the broader case. Spe= cifically, does that create a new type unto itself, or does the differen= ce get elided at compile time? For instance: use int as userId; use int as productId; function a(userId $user) { b($userId); } function b(productId $product) { // ... } a(123); Does this work? Is it a compile error for mismatched types (as in Go, w= hich has this exact feature) or no? If it is, how do you make it work? = Do you need explicit casts? If it does work, have you gained much sinc= e it's no more useful than docblocks? If it does work, how long before = SA tools turn it into an error anyway and make everything more complicat= ed? (Because you know they will.) Does the same answer apply for longer type aliases like the nutty ones i= n the earlier examples? =20 These are the kinds of questions that need to be answered before any ser= ious RFC could be attempted. Answers for them can certainly be found, b= ut so far no one has really done the work, in particular around how to m= ake aliases cleanly global. If you're interested in tackling that, fant= astic; I think most people would be on board with it (especially for fun= ction types). But be aware it's a not-small puddle you're wading into. (I think Danack had a writeup similar to this but it went a bit further;= not sure where it is off hand, but he probably knows.) --Larry Garfield