Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117685 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 62992 invoked from network); 7 May 2022 09:16:50 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 7 May 2022 09:16:50 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9966F18005C for ; Sat, 7 May 2022 03:54:48 -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-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (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 ; Sat, 7 May 2022 03:54:48 -0700 (PDT) Received: by mail-wr1-f51.google.com with SMTP id u3so13209342wrg.3 for ; Sat, 07 May 2022 03:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=craigfrancis.co.uk; s=default; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=1w1QZEFfXmvIKVl/4rICP279XM6e1pl4DLkQCc5i8OM=; b=Jy/fzjjcqvAto5hz38QYDhfIuJS2Gg9CCYoos9TEv6ScVf7RZVyHYzWvYfk5iFdzMC 8pbfTlPaYCY4OvZ0QL3+n0T+tF0YIUCtjfkoE2+eqSxEWw1terfmsyoIsQpf2nNvJqbx 42GLqCE6Hdm/x0ObWrJLe1xphWi1oYCJKg3Dk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=1w1QZEFfXmvIKVl/4rICP279XM6e1pl4DLkQCc5i8OM=; b=1rbubqEzWYVSY9pnRYZAF1OGJlMW/eI39imZTlvwAXDKzflvGzTY2YL0OE9muS9s3/ mhvgDbfphCGXNKVb+rI52wKsaLfogFFW7priNqdmbydCQhhkhWQEdG1MTJtgFjMVp9p5 0tgwKeY842LrStp2fp4YN4xpIzkia5gDyXQJJdCgqgqrYbtnJHMQG0nnrFd3dPEz0kAM ILabWuMX+8lr47GWtM6paGb3aNu8N5hxTEpo4yBuUd+bnjDktQpSsZ9c5oBBO8C4eJbw IPFcqHBoSs9/fBzA6HsQiD5eyLtOD3CfjuGSDoFFQbyVu44wBc0BUuJLo6I2gPgKMKbz opRw== X-Gm-Message-State: AOAM533r2jN2w3yP++T1lRS5E+jU3KlR9Hr9DUxlwSDf+gZOwf5ae1AI 0M+Sug13uYW6EvrDxoC5Vzj7YQ== X-Google-Smtp-Source: ABdhPJwb6T3ZmHLTpp4xNdRXklMYzuHkPKyag56RSW7MjgHeH9rxP9DJGACi4/GDxj7owNUGs5mDvQ== X-Received: by 2002:a05:6000:242:b0:20a:c4aa:d070 with SMTP id m2-20020a056000024200b0020ac4aad070mr6172958wrz.606.1651920886902; Sat, 07 May 2022 03:54:46 -0700 (PDT) Received: from smtpclient.apple ([94.173.138.98]) by smtp.gmail.com with ESMTPSA id n16-20020a05600c3b9000b00394699f803dsm6703410wms.46.2022.05.07.03.54.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 May 2022 03:54:46 -0700 (PDT) Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_68EC144B-B9DA-4322-B70F-F5F1CD147B91" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Date: Sat, 7 May 2022 11:54:45 +0100 In-Reply-To: Cc: Jordan LeDoux , PHP internals To: Marco Pivetta References: X-Mailer: Apple Mail (2.3696.80.82.1.1) Subject: Re: [PHP-DEV] NULL Coercion Consistency From: craig@craigfrancis.co.uk (Craig Francis) --Apple-Mail=_68EC144B-B9DA-4322-B70F-F5F1CD147B91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 7 May 2022, at 10:01, Marco Pivetta wrote: >=20 > Hey Craig=20 Hi Marco, Thanks for your thoughts. > On Sat, 7 May 2022, 10:39 Craig Francis, > wrote: > Not what I'm going for... but anyway, to get an idea of your position, = do you think the string '15' should be coerced to a number, or should it = fatal error as well? e.g. >=20 > $my_number =3D round($request->get('my_number')); >=20 > Passing '15' for `int` should throw a type error: this is why people = (slowly, steadily) opt into strict types. I don't think everyone agrees :-) > I mostly refrained from commenting on this RFC thus far exactly = because I'm already "out of the woods", and I already add strict types = everywhere. >=20 > Still, when upgrading legacy PHP apps, I would have to deal with the = problem, at which point I prefer looking for type errors in internal = function calls, than looking for changes in null coercion (the one = proposed here) everywhere. >=20 > Practically, my idea is: >=20 > * coercion rules are old and well known > * changing coercion rules around `null` drags in complexity > * focus should be in migrating to strict types instead >=20 > Regardless of the output of this RFC, people upgrading to 8.0 or 8.1 = will already experience BC breaks in internal function input types, and = adapt to them. I will note that my RFC does not change NULL coercion (why I quoted the = documentation), and I'm not against the other BC breaks where certain = type coercions are clearly problematic. It was 8.1 which introduced this specific BC problem (with ignorable = deprecation notices)... and while that change was to begin alignment = with user defined functions, it's the user defined functions that have = been the oddity (i.e. do not use NULL coercion, unlike other contexts, = such as concatenation, =3D=3D comparisons, arithmetics, sprintf, print, = echo, array keys). Personally I think it should have been user defined = functions that worked with the "old and well known" coercion rules, and = doing so would have reduced complexity (i.e. working in the same way). I'm also not against increasing strictness, and some of the type errors = (ref previous emails, and noted in my RFC), but I think it's more of a = balance, where an overly strict environment creates different problems = (e.g. making the language much more verbose, and can be unnecessarily = hard to learn/use). But my focus is on upgrading existing code, and this one is difficult to = find and update (e.g. the lack of tooling to help). Craig --Apple-Mail=_68EC144B-B9DA-4322-B70F-F5F1CD147B91--