Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:121700 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 69212 invoked from network); 16 Nov 2023 20:41:42 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Nov 2023 20:41:42 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8E659180031 for ; Thu, 16 Nov 2023 12:41:42 -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=-1.2 required=5.0 tests=BAYES_40,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-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (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 12:41:42 -0800 (PST) Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4083f613272so10928655e9.1 for ; Thu, 16 Nov 2023 12:41:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700167300; x=1700772100; darn=lists.php.net; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=CmRVW51aKyUekod2vgX67VDxmoHZW3jf/4bMcowsaIA=; b=nozSZU82mMLihFNuw+/r1N0qMbaCX3P0JJYv5SbRBOZx4q6McOv35qNv7yhVyXjRva yzZt8qlrKdg5N/2JkspwBl+7bEy4tepN9kLPwH3sOGEEs6tCpOyg0qBItyqYPGaHQzHB P+mWxNWHG4/qvuCa3KVUnvAW5m0yV7H+ygsJpFYLktm4MqlsV10ihDHpzHQZSF+0+/o0 WIqPwuuAhqIw8SDvZPi7jPX1iznjBnZiI7ogfbGYniJUrtVz5QcpxNlG4kxPIVnHsK6l 9sdfyGv3SynRfsYLEgOSlaWkpAYFg4jIxxzAoYbqzIZr574YvFhqAk+82r/ec7SaElco lOGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700167300; x=1700772100; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=CmRVW51aKyUekod2vgX67VDxmoHZW3jf/4bMcowsaIA=; b=eoFspl/m/uyNoQy7/ewZw7xd9tczRW/X8OLqHkjtgN7ZX7P3CWL7l18AoMzhn90r+F dFKCMp0I5TEbjts9odW2utkbjiC3YJanYor9llF3T8W+U5Po16tEdHT58I+xyBMHQLnv XGOsEG+94PWyQk8mQ4g4+qx46AFvoRD2nGw9oNwG67CFvObxQsQc3oUgoPCI7H8cRyEl ddfaJJfe63lWznDsCtlzeEUk2s5XA2MPgayeJviMJl5kKFRpuVrBXJTbrB0GKrZQPDaW 8OlWaed+oJZNXPxQ3XhDKIUHhJV4SBPJ/xsZyUu+vX3udWFBgiWOFY1ox1nHZ9G/+11s iKmw== X-Gm-Message-State: AOJu0YztCALpOFPkdqPWLBh2TFruYONEDMBLPbqfQj+RNLxpLQaN7pbh ZfIlUtj1XrMrV0dq0nr1PwKOW/Rz1Rw= X-Google-Smtp-Source: AGHT+IG/3xuFWL+nAsVxJFbbfQIZKNdMHKGiP4IIchxCIoHNbnRi8EFM6K3jdLl5d9cAl7Qc68tO6A== X-Received: by 2002:adf:fdcb:0:b0:32d:a977:50b0 with SMTP id i11-20020adffdcb000000b0032da97750b0mr11193468wrs.41.1700167300030; Thu, 16 Nov 2023 12:41:40 -0800 (PST) Received: from [192.168.0.22] (cpc83311-brig21-2-0-cust191.3-3.cable.virginm.net. [86.20.40.192]) by smtp.googlemail.com with ESMTPSA id d19-20020adfa413000000b00327bf4f2f14sm321361wra.88.2023.11.16.12.41.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Nov 2023 12:41:39 -0800 (PST) Message-ID: <2b4591c1-f999-49b5-8061-67db816aa0da@gmail.com> Date: Thu, 16 Nov 2023 20:41:38 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-GB To: PHP Internals Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [RFC][Discussion] Harmonise "untyped" and "typed" properties From: rowan.collins@gmail.com (Rowan Tommins) Hi all, 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 Currently, changing a property declaration from "private $foo" to "private mixed $foo" changes its behaviour in significant ways, even though no actual type checks are added. This RFC seeks to remove those differences, by extending the "uninitialized" state currently reserved for typed properties to cover all declared properties: * Properties without an initial value will be "uninitialized", not "null" * Calling "unset" on a declared property will make it "uninitialized", rather than the current complex behaviour There are a handful of open questions still in the RFC, but I wanted to present an initial draft to start the discussion, because the current behaviour is quite hard to explain in a short e-mail. Please let me know your thoughts. Regards, -- Rowan Tommins [IMSoP]