Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108282 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 28181 invoked from network); 28 Jan 2020 10:56:04 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 28 Jan 2020 10:56:04 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 305581804F6 for ; Tue, 28 Jan 2020 01:06:25 -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, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS 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-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 ; Tue, 28 Jan 2020 01:06:24 -0800 (PST) Received: by mail-wm1-f49.google.com with SMTP id g1so1588481wmh.4 for ; Tue, 28 Jan 2020 01:06:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=62uHllEuvLxHwLqzQTR9lCDUjyfpGkh4NAv4OGjX6k0=; b=grXT8j3ena9IyrXPRRSBevNkUIQhrlJcmlkXYxAzs5bDi9axc+dABJjsHNzmxaHFSe y5iBwOMUvrvQFaheSSn2bd4mTdsKXm46VaUG5B668s1Z9wscEcUgO9lMiyVIUsMNmx5i IECy3fnRFGzDb/fRZDkqv+jv3aS6BxvVnt/E8Lr84msqpHjvdwnQoykc4iUSI1iZx+RT x5xOUe3FUNriRN7DbNRh0vcup/RSHwjhuuj/ZRPr5h4tb9dGawzwswuQkP0mLiF9qPpG 0vSOBby2Jl1cjEw1Zar7PWTHh4DUhdk1OjOgytJUmbPcbRHXcH1wNmI8fRHP/hb0vSLj gnpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=62uHllEuvLxHwLqzQTR9lCDUjyfpGkh4NAv4OGjX6k0=; b=Q5cfU03j91MYuWvhufymXRyUg3pQj0la4P1lfwPVeMoYIc8kxdXLwOWxgEtRNDRV1T UIrJqHLkHsN4fKN/ikzWQ+pUiGaXAn3sZfm2JnMqTMvG8BESP1agR2YM/HUECKWktP5Z xwrR53ei8XTBC6KJXOw22RkqCzi7PlaOZd/TAaeDS5AkzUUINo+LbP76kWwKydTQKee+ VCiaeK0Vq/D0jpqJXqgOr31Q01NFcxNUppsNb5Ct3Ns3H5wh67/rIRDHbUd8Cfj0OUsG /j5xLpNe3C82EbbYaLTT6SrmUWNVk4lHl3pbx37kGroWNKCwc3WE161tWCcQPguN6erq jSxw== X-Gm-Message-State: APjAAAXR3ILwOoKmM5qXxYbdT2Fn2K0P5ZqwwJT0PxaYOwDPinMD+0Me goZ3xyt4LNcZqr9hPEZl6Eqh7kuS X-Google-Smtp-Source: APXvYqxRXy4f7UHDbPOdG5iboKvgXqwoMALHlx+QiipCodl6OcYdHdaDJfyB7wFQMjjb1fZ3SPNddQ== X-Received: by 2002:a1c:5419:: with SMTP id i25mr3797428wmb.150.1580202382460; Tue, 28 Jan 2020 01:06:22 -0800 (PST) Received: from [192.168.0.14] (cpc84253-brig22-2-0-cust114.3-3.cable.virginm.net. [81.108.141.115]) by smtp.googlemail.com with ESMTPSA id d16sm28169250wrg.27.2020.01.28.01.06.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jan 2020 01:06:21 -0800 (PST) To: "internals@lists.php.net" References: Message-ID: <2d50c8c0-cbd1-0a0e-4098-eb00facf86db@gmail.com> Date: Tue, 28 Jan 2020 09:06:20 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Subject: Re: [PHP-DEV] [RFC] "use global functions/consts" statement From: rowan.collins@gmail.com (Rowan Tommins) On 28/01/2020 01:06, tyson andre wrote: > I don't plan to change the default name resolution behavior in PHP 9, though, > and if it does change, it might even be according to a different proposal, > so adding 'fallback' as a third option before we know what type of change is planned > seems premature. I still don't understand this logic. If my code is written so that it needs the current "same namespace fallback to global" behaviour, I don't care what the default mode is, or how many other modes there are, I want to make sure that file will continue to use that mode. The *only* way to do that is if there is a directive saying *explicitly* that I want that mode. In other words, we don't need to know what the future modes are to know what modes we have *right now*, and give those modes names. > I'd imagine the migration to 8.0 and 9.0 would be similar to 5.6 to 7.0 That's not the point; people want to be able to run the same code on multiple versions; the sooner we include a forwards-compatible option, the more versions code referencing that option can run on. I'm not seeing the downside of adding it now. > I see `strict_types=0` as similar - The value `0` is currently rarely used compared to leaving out the setting. > If php 8.x were to become stricter about type casting by default in a few ways, The difference is that we could change the default in a future version to be strict_types=1, and people could run code with strict_types=0 on both versions with exactly the same effects. That's not the same as saying strict_types='default'. > I doubt that there would be an argument for creating `strict_types='php7'` before we knew what those changes are, We already have created that: strict_types=0 and strict_types=1 can retain their current meaning, and any new mode can have a new name (strict_types=2, strict_types='php9', whatever). To be clear, I'm not suggesting 'fallback' is added as a third option, I'm saying we should name the two options 'fallback' and 'global', just like strict_types has two options, 0 and 1. I can't think of any situation where I would want a change to the default mode in the engine to cause my code to be interpreted in a different way, so a 'default' option makes no sense to me. Regards, -- Rowan Tommins (né Collins) [IMSoP]