Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:121702 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 74693 invoked from network); 16 Nov 2023 22:14:19 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Nov 2023 22:14:19 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id DFA6618002E for ; Thu, 16 Nov 2023 14:14:19 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-qv1-f48.google.com (mail-qv1-f48.google.com [209.85.219.48]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 16 Nov 2023 14:14:19 -0800 (PST) Received: by mail-qv1-f48.google.com with SMTP id 6a1803df08f44-677a4d9ba82so6924566d6.3 for ; Thu, 16 Nov 2023 14:14:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700172858; x=1700777658; darn=lists.php.net; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=1mrtRN8jIkPJbgeJRUvR65Pekw184SCQp7iPJsTAYfI=; b=ezd6TYxff++w9BoLZOx/99dMfMap6IjA+Wl5X0cHuWVG+Cfbp7M6LjHrfTMV6V1q/T qrE/tvCzMrm7BjQs0t4DIj4V2CeqZUeinT1zgNui23TuGDwCNbR7Lpw4Cvr+cNU5fqao zBZa0H+VyA6fev29RBf4/F+8YG7g6HjQhM4/XjkDO6QZuegCxWSpT9ZCewHf3uoQUrex upd1Z97dnAQjF+KPunlmuyRiyZ05EzLgyRKTvNBcZ4bSZCAIF4Xp13wjoULy9mpTVwfy TlKMuo/Ztm6tn3ha9e1K6vlbHQAjmDQKBE8NfmudWb1X380y8ldCBzwcLQAqmDeH+H6d m66A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700172858; x=1700777658; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=1mrtRN8jIkPJbgeJRUvR65Pekw184SCQp7iPJsTAYfI=; b=Ov07N3qRv0HQ7j0nQw/IZ/B9Onpar1ws9gUEe2+U5/+1dWguGEkYynl+gX+XTjw9cg 4yQl/aAVZKpVvr1k2ragDSb9HHCQH5qXp1k41D8GauQVvEMv4K/yfMYHcQLrdVEZTQO0 LLivotA5Oi81+U0e00h968AzFiZPMNvzr3B3Y+o1EvJJGz1XIoYeLCM1wVfbTaj0HUOu j5L2uGDJjlYrM9xJb5zF0TY+v7sRlGrP+k/giTujgDKbfWSn5dOVEdgpPsrp3V5UG5lu K2dmCMKZePkifTMHRHZUBQ7VvfN0FpTx/xxYCY3JT/7r2QDGxo/0wpc2dFpOtCzfkbFA /ZyQ== X-Gm-Message-State: AOJu0YxiYI/AApevcOqxAKzAMzFFFGpG6LQhwaQCVD8by+p4mny8JHWt N0f3YZ/pjuXoSJD+rhHMmjj4qT01pwc7Kx8oNMsBUHnFifyQ+3b1 X-Google-Smtp-Source: AGHT+IE8DpcuE9uaIVHK/F8ooPYTriFQZpYMLcbvfkV/pYnGud/sVZUNYmYOYUhzJ4ZCc66ngmffJcnuFaYKS8gODLw= X-Received: by 2002:a05:6214:1850:b0:671:49d7:6077 with SMTP id d16-20020a056214185000b0067149d76077mr8892460qvy.30.1700172857723; Thu, 16 Nov 2023 14:14:17 -0800 (PST) MIME-Version: 1.0 References: <2b4591c1-f999-49b5-8061-67db816aa0da@gmail.com> In-Reply-To: <2b4591c1-f999-49b5-8061-67db816aa0da@gmail.com> Date: Thu, 16 Nov 2023 23:14:06 +0100 Message-ID: To: PHP Internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [RFC][Discussion] Harmonise "untyped" and "typed" properties From: tovilo.ilija@gmail.com (Ilija Tovilo) Hi Rowan, Thanks for the RFC. On Thu, Nov 16, 2023 at 9:42=E2=80=AFPM Rowan Tommins wrote: > > I have finally written up an RFC I have been considering for some time: > Harmonise "untyped" and "typed" properties > > RFC URL: https://wiki.php.net/rfc/mixed_vs_untyped_properties Unifying the unset behavior sounds sensible. I don't see a good reason for a declared property to be hidden through unset. If this behavior is desired, the property should be declared dynamically in the constructor with #[AllowDynamicProperties] added to the class. Like Jakub, I am also worried about the BC break of changing the default value to uninitialized. However, I don't think opt-in behavior is worthwhile (because I don't believe people make sufficient use of it, while adding something new we have to support forever). If we pick either of the options you presented (1. initialize all nullable properties to null, 2. Make all properties uninitialized) I'd vote for the first one. Then again, given (it seems) people are happier with the strict behavior of typed properties, do we need to unify the behavior at all if it means losing that? Currently, they can choose the behavior they prefer by adding or omitting mixed. Furthermore, the first approach clashes somewhat with readonly. Readonly can't have null as a default value because that would make it legal to access the value before the property is explicitly initialized, and the property would no longer be uninitialized, making the explicit assignment illegal. We could just not add the default value for readonly, but that means more special rules that we're trying to avoid. Ilija