Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117521 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 36613 invoked from network); 13 Apr 2022 12:04:55 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 13 Apr 2022 12:04:55 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 3BBEF180510 for ; Wed, 13 Apr 2022 06:36:55 -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,HTML_MESSAGE,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-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) (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 ; Wed, 13 Apr 2022 06:36:54 -0700 (PDT) Received: by mail-lj1-f172.google.com with SMTP id b21so2234294ljf.4 for ; Wed, 13 Apr 2022 06:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=craigfrancis.co.uk; s=default; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lUSuGOtKzsHgAQ1Xw48LkGqHkYSD2A1vZB9HpDvML8Q=; b=U8xxxGuGtVs7kxNTqKhKjwTceGyWnPUTL5NOB0oatV2kk2zlG43rmGArMx2N8/chB/ pjJv+Pvui9YiA80IHOO9F1IQhoV/Lky70nO4nlGs/sKvYKewD8IqXH5kdWSCKpArw+B7 /bJ9Nd2goMOQyVl56IMaOG1n2kiiTdq+gg49o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lUSuGOtKzsHgAQ1Xw48LkGqHkYSD2A1vZB9HpDvML8Q=; b=wh0qg09TRM2ANnkZOpxoHskKzdnhY2tBQDsz7CHqLjJcUnTN48al+w7mPIZ+RQHcmG VMVzxJInjAEWELPiDiK6s7I7zSqp4xch1zEuL2Mq3YkQpxXP9hfpQegUmosS/OcpHxRn ougO3T9jyv9Iwq2ogLGlxPTNHaBqZdk7QHkBKxj+DVsthK0g/Kv8CPAmPBkiLQK8BPtk yCWXbJ6O9Ct9aYHZyt4DAUO/+AgqYJZht2whfxzNFw3JHliGMbGrVEVIrA6N1HfnwH+x QcmeRzStb73d7bmY3EMoQcfKHfQz8w48zi/nnk2Huvn5IG3IN3LiZGcwfOlTUiyt/0S9 qk8g== X-Gm-Message-State: AOAM5335peSu6O9g3cPBBy586PREz0ZmvJqzCrmPBfbmztSXY0zZvtkS jleoQWLFwP1ie8b0/edozqMMC+R3LBQsBIcY3MpcaA== X-Google-Smtp-Source: ABdhPJwf/mRXUfRYVqbaQnXWXDIipFm/GEMhssYPCn59hQ6Df4JkQmlE99l8V/e6F/ErOEvqqH9S5ZT0q/YFbQN5knk= X-Received: by 2002:a2e:9ec5:0:b0:24b:536b:7e28 with SMTP id h5-20020a2e9ec5000000b0024b536b7e28mr16239814ljk.120.1649857012981; Wed, 13 Apr 2022 06:36:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 13 Apr 2022 14:36:42 +0100 Message-ID: To: Andreas Leathley Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000307f1705dc8945c6" Subject: Re: [PHP-DEV] NULL Coercion Consistency From: craig@craigfrancis.co.uk (Craig Francis) --000000000000307f1705dc8945c6 Content-Type: text/plain; charset="UTF-8" On Mon, 11 Apr 2022 at 20:08, Andreas Leathley wrote: > You are taking parts of the documentation out of context, and omitting > the start of the whole "Converting to string" section: > > "A value can be converted to a string using the (string) cast or the > strval() function. String conversion is automatically done in the scope > of an expression where a string is needed. This happens when using the > echo or print functions, or when a variable is compared to a string. The > sections on Types and Type Juggling will make the following clearer." > I'm sorry, I've read this several times now, and I'm not sure what this adds. My RFC simply quotes the paragraphs that explain how null is coerced (other than the small abbreviation for booleans, those paragraphs are included in their entirety), I don't think it needs any more context than that, it's not like I'm mis-representing how coercion works (and is used) in PHP. I could expand my first quote to include "... For example, a function that is given an int for a parameter that expects a string will get a variable of type string", but I don't think it's that useful. > In the same section it is also defined how resources and arrays get > converted to strings. Following your argument, you should be able to > pass arrays and resources to a string parameter because there is a clear > definition in the documentation of what then happens. > No, my RFC is about the problems this change has caused, how it is making it difficult to upgrade. I'm only referencing the documentation to confirm how NULL has always been coerced. I unfortunately really don't like the direction of your RFC, because I > see null as a real type and because it increases the divide between > strict_types and not using strict_types. I have never used strict_types > - in modern PHP code I find it unnecessary, if you use parameter, > property and return types. I am glad PHP has decreased the difference > between using strict_types or not, so your direction of trying to > increase the difference seems like the wrong way to go. Ideally I would > rather want to see a future where strict_types can be removed/reconciled. You can see NULL however you like, but most developers do not share that view. NULL has been passed to these functions, since, well, forever; and changing code to manually convert NULL to the relevant type is incredibly time consuming, and of questionable value (e.g. when developers simply add strval() everywhere). Either way, I'm not trying to "increase the difference" (this is how it has always worked). If you want type checking, good, it can be really useful, and I recommend it with static analysis... but it's enabled with `strict_types=1`. Craig --000000000000307f1705dc8945c6--