Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118719 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 87068 invoked from network); 30 Sep 2022 17:40:05 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 30 Sep 2022 17:40:05 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B87FB1804A9 for ; Fri, 30 Sep 2022 10:40:04 -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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) (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 10:40:04 -0700 (PDT) Received: by mail-lj1-f177.google.com with SMTP id a14so5530455ljj.8 for ; Fri, 30 Sep 2022 10:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:from:to:cc:subject:date; bh=oe6Esg/+imBIBf7KsrxxG5PlHy0Hzs0evDB2O7csqDc=; b=F7jHUoIjZyMbohjaOZA+E/6Ms9AWALRuztnLVxMJTbrq3Meqd+l4Szodx72H8d2E7Q uJG/890hA+Ucz2FKPRcG8UgixstGZR2UhKJ8x5dEtMR83nVfPbHLrwDAchs9ohxlHjW4 DeHtt2qBbDZgb6+YhJuHzoF4ZsTmOa8oVGuGxkhfSbA//rlCwVgMwsmZ4OMjiMb91rv7 j56WzV/qGdmuGPhl5U6e/UyN7N3GcW4AH+fm+1svetL9e1IJTD87Z4h8TpVSKEIfBcYP V3AygoCwf0R6OHhwu86T53YZt67Rj6Ho7MyzD1cmXlCFbDOXZiOU+nqxxvc9S723Tf2m ol7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=oe6Esg/+imBIBf7KsrxxG5PlHy0Hzs0evDB2O7csqDc=; b=qUzFuOcto3lWBRuGlmmC7bpny3DfcEgT9FFUJheHgUNILqTGDQUM2fIErN9abN7Q9A wlwCA1I1inV3Ojdw+Yu5VoDBUUKJAtGj2yVtTfVUgB1kKLt27lWrooqhxztpkIMcSNdn To7rXPKhKjOAlcxOF5ebAufwLNC1ZnbYZD59J2B2Ratq37alJEpCLMsSmBEkHnMfQNaE 27hReTF9e6C4Bna73wlRDJLOL7sB74qeRijOEor13Wjdur4iJ/v8lQMdMtBWadHFxrFF /OmryGYF6ZkbmVUNlqGGbKSkBtUb2qrvyxMr5J2qfGA5PSQ5sKSrUIO82SwTNJdplcQZ SpHA== X-Gm-Message-State: ACrzQf3JuunUfG+JlIszpJWoWOtsr4uDLCuGQnWuMKifgEPSUVNYYeRc Iwk9uU5VKRis0oeludj57zcMdOhyMxC9hgxcJi1Y9uaC X-Google-Smtp-Source: AMsMyM4GyOUZFBSksUD5VijYjPbIxYb8NzH15wZ59/3Nm0cqhWaqMgzX88ypWSy1/ywIHsTJpy7PkWwm8h60Epe47qQ= X-Received: by 2002:a2e:7d13:0:b0:26c:4062:acfe with SMTP id y19-20020a2e7d13000000b0026c4062acfemr3329229ljc.201.1664559602403; Fri, 30 Sep 2022 10:40:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:5303:0:0:0:0:0 with HTTP; Fri, 30 Sep 2022 10:40:01 -0700 (PDT) In-Reply-To: <38350298-6aaa-4739-b927-0a9423baae4e@app.fastmail.com> References: <38350298-6aaa-4739-b927-0a9423baae4e@app.fastmail.com> Date: Fri, 30 Sep 2022 19:40:01 +0200 Message-ID: To: Larry Garfield Cc: php internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Re: Alias for `int|float` From: olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=) 2022-09-30 17:16 GMT+02:00, 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. Ya ok, not what I could find in externals.io ^^ > There's definitely > interest, but like many things it runs into the problems of time and > figuring 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 > all 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? Yes, you would. That's the limit of my current suggestion. Same semantics as use-statements. > // 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(...) Neither suck. :) Just "normal" inheritance boilerplate in the absence of project-global type aliasing. Do you have similar counter-examples for non-OOP code? > } > > > This becomes even more of an issue when you start talking about function > types, which is often mentioned as the primary use case. > > 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 > improvement. It's an improvement for readability, especially when repeated in one file. But my suggestion does not include function-types, because there's no such thing already in the system. Just to let use-statement include more of already existing types. If function-types were added later, they should be supported too, yes. > > 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. Yeah, always better to have a clear limitation, is it not? :D > The degenerate case you mention of simple type renaming has its own > interesting implications, which are also a factor for the broader case. > Specifically, does that create a new type unto itself No. Keep the same semantics of the current use-statement. But it could be a future extension, sure. But then you need some kind of "factory" way to produce those types. In FP they do it with "abstract types", where the implementation of a type is hidden from outside the module. In PHP, maybe with Foo::make() functions or such. Different discussion. > or does the > difference 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, wh= ich > has this exact feature) or no? If it is, how do you make it work? Do yo= u > need explicit casts? If it does work, have you gained much since it's no > more useful than docblocks? If it does work, how long before SA tools tu= rn > it into an error anyway and make everything more complicated? (Because y= ou > know they will.) Not sure I agree with you there. Obviously, static analyzers would have to abide to the semantics of the core language, no...? > Does the same answer apply for longer type aliases like the nutty ones in > the earlier examples? > > These are the kinds of questions that need to be answered before any seri= ous > RFC could be attempted. Isn't an RFC a good place to document all these cases? I was thinking that an RFC could be a good place even for things we do NOT want to implement. to help pave the way for features we do. > Answers for them can certainly be found, but so far > no one has really done the work, in particular around how to make aliases > cleanly global. If you're interested in tackling that, fantastic; I thin= k > most people would be on board with it (especially for function types). B= ut > be aware it's a not-small puddle you're wading into. I never had a need for such a feature tho. :d Although my motivation for current concept is also dubious (transpilation to C, mainly). Maybe generic-notation for arrays is more relevant to improve type-hints, buuut that's another can of worms, and I didn't read up on current discussion yet. :) Thanks for the feedback, Larry! Can I still get karma to write it down in the wiki? Again, not to necessarily encourage implementation, more for documentation purpose. And I prefer to have it on the wiki, to keep all the docs central. Olle