Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113549 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 79389 invoked from network); 15 Mar 2021 19:45:32 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 15 Mar 2021 19:45:32 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 85A6C1804D8 for ; Mon, 15 Mar 2021 12:39: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=-0.2 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 15 Mar 2021 12:39:06 -0700 (PDT) Received: by mail-ej1-f42.google.com with SMTP id bm21so68278045ejb.4 for ; Mon, 15 Mar 2021 12:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4PCsPThQYaC8MicTvmcHp2i3WLU2fJtCHUqKkxW9vEY=; b=N97Q19IMaGY2i/1a5K6HVKNdXiwsi+4sNUSBstG8huzm1lROzzKsdPs8VHVDXLgmad RNnjIz299RqgP7pxo5cO600NSxTaclUqLJsbK1YzQduc24IiaEbC1MryLA29qL6rkI2z psvVb598oUO0ZyIFVg/5aFtIDYCF5MqvaaUOYpLQ8iS1C636MdVH99frbdqqgTOTss7L +kbHqHf/gg9KEVKyUi4VvrCcIdB5Xm5HTSUZKhIV+0a6/XOjYzPe6fkz5U0IMPclxQKI mhkrHl10m2yw7xyyzHki8CxLFmGs5v5fwa0klGZ5ln/cdYg8xyyVqD+Nl/ffzL13iuG6 2eqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4PCsPThQYaC8MicTvmcHp2i3WLU2fJtCHUqKkxW9vEY=; b=HbbnORAhPHHWuq4VBvA84r7tteko+KaSImnw6JpiJyRMXGCkOa6aoaNYJtdEpLFyzA N2PySx7EUkdRDJov0QVmRPowPMkrLXm6K0oueT4mI3dm+kjUcSFFbXj4/kof2vrzcIId +qWVA7bsGXFlgLaRwMkUAMenQL3MkMA/OKxxDfHkZAfflR3lDPBccjYqLF8zv7dsXk1l 6iTM1Xc52u1rWRIbBGjmMvlocvs3i2BjLPw9aaSTJUfth5JQNeZFxWwO1ngYAYhtCLKh rQuRqqlTgmVCs70ajzLvkFI4RbzxwHK8DefpBxzjpEcxwgAPRuF1jneqpGyzv+gSdJc7 kR0w== X-Gm-Message-State: AOAM533wN91/3QaZqNuX9ABzBHZFy8NWrToUlEx19r1tKUI0X/mRdz7r FXvnd8uhiItirH4nWJJ7VzPh5dNqvFiSyxAPfes= X-Google-Smtp-Source: ABdhPJwY+NWXXRMwufDc0+PD23PKZ91R0pm+m/h91jwv+qrThJcfsDhTNSRrVELfGqa0q/Mc0S6oV2uO85xeq9iusJA= X-Received: by 2002:a17:907:d8a:: with SMTP id go10mr25848722ejc.46.1615837145652; Mon, 15 Mar 2021 12:39:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 15 Mar 2021 20:38:54 +0100 Message-ID: To: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= , Nikita Popov Cc: PHP Internals List Content-Type: multipart/alternative; boundary="00000000000014e18705bd986741" Subject: Re: [PHP-DEV] [RFC] [Discussion] Adding return types to internal methods From: nicolas.grekas+php@gmail.com (Nicolas Grekas) --00000000000014e18705bd986741 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi M=C3=A1t=C3=A9, 1.) A few other people off-list also shared their negative feelings about > the E_STRICT. So I'm ok to use E_DEPRECATED instead. > Now that I implemented the suppressing mechanism, I think using a separat= e > error type is not needed anymore that much. > Wonderful! > 2.) Unifying the TentativeReturnType and SuppressReturnTypeNotice > attributes is an interesting idea, and I would love to get > rid of the latter one. Although, my concern is that doing so would > eliminate the possibility for an overriding method to declare > its own native return types (it's possible that they've already defined > return types): so any child class could literally define > return types at its own will, while it was not possible to do before. I'm > eager to listen to any solution that would address my concerns. :) > I'm not sure I get your concern: how would #[TentativeReturnType] conflict with native return types? I didn't think about it, but #[TentativeReturnType] could be useful to raise a deprecation when a supertype wants to tell child classes that's is going to tighten its return type, and that they should do so if theirs is too broad. This is basically a generalization of what we're talking about, isn't it? > 3.) I'm not sure you noticed in the PR, but in fact, I also implemented > the TentativeReturnType attribute. Currently, it can be used > as below when DateTime::modify() is overridden to return the ?DateTime > type: > > class MyDateTime extends DateTime > { > #[TentativeReturnType] > public function modify(string $modifier): ?DateTime { return null; } > } > > How does this syntax look like for you? > > Compared to your proposal, the main difference is that the attribute > doesn't itself store any type information, but it's done among the > function information as normally. Oh, I didn't get this at first: you're telling that this native return type would not be enforced when the attribute is declared? This should answer my previous comment. I'm not sure yet this is a good idea, because it would prevent userland libs from using this attribute in an effective way until they bump to 8.1... > In my opinion, the current implementation > has multiple advantages over the one you proposed: > - As far as I can tell, it would be *very* cumbersome to parse and valida= te > type information from strings, rather than reusing the > capabilities we already have. But I'd be happy to be corrected if I'm > wrong. > - Apart from the compiler itself, I think parsing type info is more > straightforward as currently implemented for users as well as any tooling > Maybe Nikita can shed some light on this (the 1st item mainly)? > - We should also think about people who already declared return types for > overriding methods. I don't see any good reason why they > should repeat this information in the attribute. > In my proposal, the path for userland would be: - in their next minor (still supporting PHP < 8.1): add the attribute; - in their following major: user a native return type and remove the attribute. > - I'm also not sure how the attribute could be used to retrieve the > tentative type? Should it return a ReflectionType? Returning > just the string representation seems like subideal for me. > It would contain a list of strings in my proposal, to keep things boring and expected yes. Nicolas --00000000000014e18705bd986741--