Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112233 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 97838 invoked from network); 11 Nov 2020 23:35:29 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 11 Nov 2020 23:35:29 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 7A22F1804D9 for ; Wed, 11 Nov 2020 14:57:58 -0800 (PST) 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,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) (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, 11 Nov 2020 14:57:57 -0800 (PST) Received: by mail-ed1-f67.google.com with SMTP id t11so4027936edj.13 for ; Wed, 11 Nov 2020 14:57:57 -0800 (PST) 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=9M0mcrA8pYF36eBBg/pQJgx21NhjgkphGFGRKLHW3YM=; b=D1pCewgF/YdxXxGu1q4Siv5Y0MUdT4fzUXnRZY4iZ0/mx2/GgorFTP1XF3TjXBv1yV 9JkfGTEc/5SiOtcSgIv3pGzZSm02ijGGonNK/l+dQczstB1O4CEWmGQ4ieo5C6MLsr2G 3ymsZPBCGYSFYzeLpkQQfqj3Hn5mJUIEVC4gfa3UhERntEp9FjZHD/T91FJ1h/qDrvpt PGbTGDf1HDi664YW1+0tJf6cqMZEDHjcnevCEJP53vS05heEowhYQdzBLnxN4cwPMmXD s5TjRc9w5Jgcnj7EkmwlNpKRpH3iDcM9eEs2Ha7ZnQAqlaDIc+6QOfsqO7lFln4FvFnb 8dDQ== 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=9M0mcrA8pYF36eBBg/pQJgx21NhjgkphGFGRKLHW3YM=; b=pZkm9EPWUsbA3b93pzHD5LFXmCpDCvUu+x+yOZJ+dR2u2nZ4Mch8LsaXPtmkFIvRo3 iGmbN1Dha3Zni5OY8nm2UYF7vJcc5k0EZhYqHfx4OI9IIxe2u7IFY3anGkHMWdOy3cZQ THIl50EyT8mVXb51gD0Sw0ZBe54cdxi0DfrRZRWri2o1KFjgj7wga8UUtQdcWAdxjVjb lneHJ2KMBtlUWse6q62Oo65v8MENZYFn+GzkzAi4EhEVbdvA5w01SQ5YrB/dU1gRa+JT rt2NczAmk3+DoASJ8i/kI5J4BNgTOYamoV9H+ZPkeZ7pylFv+i/pIUg6MVlWuhG7qU3m Al5Q== X-Gm-Message-State: AOAM533XmVzHqbbbuTTe6ECl7k/i8wHNoqDGN6W9uHTtT27A7OS2KrpI W96vsUzU6X8g6xUvNVkWR2P+eXY8xjp/hcWh3JU= X-Google-Smtp-Source: ABdhPJzdio7xWP3wC32lkQ3Lw6rzBYKrErIB46KAKotvNga+3cZSmU/9jXea3bXcXMo9lpMJmhTw8OhIZsBg8g6jMbE= X-Received: by 2002:a05:6402:1f0:: with SMTP id i16mr1995837edy.122.1605135474359; Wed, 11 Nov 2020 14:57:54 -0800 (PST) MIME-Version: 1.0 References: <68aba5e0-6cfd-5946-3e01-2bccca546db7@gmail.com> In-Reply-To: <68aba5e0-6cfd-5946-3e01-2bccca546db7@gmail.com> Date: Wed, 11 Nov 2020 22:57:42 +0000 Message-ID: To: Rowan Tommins Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000c4003a05b3dcb95d" Subject: Re: [PHP-DEV] strict_types will be default at some moment? From: george.banyard@gmail.com ("G. P. B.") --000000000000c4003a05b3dcb95d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 11 Nov 2020 at 21:47, Rowan Tommins wrote= : > On 11/11/2020 20:20, David Rodrigues wrote: > > I have been asked by a friend if declare(strict_types=3D1) will be appl= ied > by > > default for some version of PHP, like 9.x or will it be always required > by > > all scripts forever. Someone can tell me? > > > > If yes, what is the reason for requiring it? Why it can't be the defaul= t > > behavior (or maybe, the unique behavior). > > > The question (which I hear often) misunderstands the original intent of > the declaration, as I understand it: the strict_types switch was not > designed as a transition mechanism for old code, it was designed as a > genuine choice between two different options, both equally new. > > Before PHP 7.0, there was no ability for a (user-defined) function to > declare that it wanted an int, string, float, or boolean argument. When > it was proposed that these "scalar type hints" be added, there were > different, strongly held, opinions on how that should work, leading to > at least 5 separate RFCs, several thousand mailing list posts, and a lot > of general unhappiness. > > The idea behind the strict_types directive was to combine two versions > of the feature into one system, allowing users to switch between them at > will. The proposal made clear that both modes have their advantages and > disadvantages. A few of those were affected by compatibility with older > code - in particular, around the behaviour of built-in functions - but > those were not the main driving factors behind providing two modes. > > Perhaps, 5 or 6 years on, things have changed. Certainly, there are a > vocal community of users who see "strict_types=3D1" as unreservedly > "better" in some fundamental way - but then, there always were, that's > why the debate was so heated. I rather suspect that most of the > arguments put forward for one position or the other then are just as > true now. > > I do wonder if people would even be asking the question, if the modes > had been named something like "scalar_types=3Dcoerce" and > "scalar_types=3Derror", and somehow arranged such that neither was in > force by default. > > > [PS: What a beautifully timed e-mail - "11/11/2020 20:20 UTC"!] > > > Regards, > > -- > Rowan Tommins (n=C3=A9 Collins) > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > As Rowan pointed out strict_types have a complicated history, and to some extent were a bandage fix, a very good one which might have been *too* good= . Let me try to explain by looking at how strict_types circumvented some of the nonsensical coercive mode behaviour. (Reminding that this is in PHP 5 days) 1. Preventing float to integer conversion, which could lead to a loss of data if a fractional part exists 2. Preventing integers, floats, and strings to pass a boolean type declaration 3. Preventing booleans to pass an integer, float, or string type declaration 4. Preventing internal functions from coercing null to the corresponding scalar type 5. Preventing strings which look numeric (i.e. leading-numeric strings) to pass integer/float checks It should be noted that all of these issues exist (in "weak" typing mode) in PHP 7 and only the last item of the previous list has been "fixed" in PHP 8.0, with the "Stricter Numeric Strings" RFC. [1] The "competing" RFC to strict_type scalar type declarations "Coercive Types for Function Arguments" [2] made provisions to some of thes= e cases, namely 1, 3, and 5. However, they were made as deprecation notices, which until PHP 8.0, were silenced by default. Case 4 might finally be solved as in PHP 8.0 a lot of work went towards making internal functions accept null (or have a reasonable default value) for optional arguments. For case 2 one can argue both ways that it makes sense that non boolean values resolve to true or false to pass a type declaration. Now going back to strict_types being *too* good of a bandage fix is that none of the above issues have been addressed during the PHP 7 release cycle which could have made coercive typing less surprising (the float to integer being the most surprising IMHO) by introducing warnings/deprecation notices and making them TypeErrors in PHP 8. As such I think, it would be better to improve coercive typing during this major release cycle by making it stricter and more akin to strict_type semantics such that the strict_type declare statement might become "obsolete" in PHP 9. Best regards, George P. Banyard [1] https://wiki.php.net/rfc/saner-numeric-strings [2] https://wiki.php.net/rfc/coercive_sth --000000000000c4003a05b3dcb95d--