Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105370 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 69524 invoked from network); 24 Apr 2019 16:11:07 -0000 Received: from unknown (HELO mail-ed1-f66.google.com) (209.85.208.66) by pb1.pair.com with SMTP; 24 Apr 2019 16:11:07 -0000 Received: by mail-ed1-f66.google.com with SMTP id u23so15540434eds.9 for ; Wed, 24 Apr 2019 06:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xWLXaY4mKpNQPfpA0QKy4P9JzWmU+GuMoqb7nMa9Cow=; b=UipqSeFl3HQgG/PGl8Gw0FxErHgbD6zZiND6lGIRyBjj80STZ30nNRqFAmj6EAROU0 MmnyNkT+uIabiLiVmwmthlvjC6ruenjzscm0wvmj7trk1Mh5eb1oBA8bxnw6peVwHGRE lww9CRCxrfMBmpcM4i1JNFMQCDhBDB1MOBkBqmhilkgJfMQuPYCekWdJm3COL6d/DYeQ HOpXCx7zqQN11/tFsKAtY8LCaeZGu2C8NiN3N6CM5PPwN3aa1/YWvn2MuMn+RyM4Itrz wGXVmAr7M+9CUBT1bWaITBWv8yqZPgX6Apl2INWKch5kytLhiD9hhVZt/bFYr9XE3BhQ 0nJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xWLXaY4mKpNQPfpA0QKy4P9JzWmU+GuMoqb7nMa9Cow=; b=hTJIRIgt68n9smsWCTW+Co4/dNZF4J+3F98WU+VCGZazaFm38O/ZMJr493moXDmTpV EceDPhGEkg0k47fdU2BgTGKbG/nQSixBz6XeiR0mKPBL89aRBaUX9O8YlcYTNKiE8UqP zpObxQQ8opMXHUyb5GmlT0a4hN4ebWRMfvtORwh5mEt3vvhDaUBsVX76HfHREdv+aoyW d9O6h0osAMoXjS8x2sw1i3cfCCada/2IWjxAfkdWd/5tZLfQI3niOHN3K4WAbkEPa03z NnVmdrER7LkIraFCqVo7sk8SFHJrP6aAPLIc3nYxYAmDNgdGaBexA9uLMbMHffAL766/ dqYQ== X-Gm-Message-State: APjAAAWggUnOOQXxVCg/jWdK6pju/dADwVCnCtf6RZeAKiGmmhmN8nFo sOjRspQW4mvc1H+pIyp3gH4= X-Google-Smtp-Source: APXvYqxcBvDY708Dwc+QDMOfjfZ0pCNOeseHSQF8i4sKG7rXH1pOAjJ3ZIY1mYDOQyoha3mswWnGbA== X-Received: by 2002:aa7:c14b:: with SMTP id r11mr20865924edp.169.1556111505726; Wed, 24 Apr 2019 06:11:45 -0700 (PDT) Received: from [192.168.0.63] (84-75-30-51.dclient.hispeed.ch. [84.75.30.51]) by smtp.gmail.com with ESMTPSA id d8sm3540945ejm.29.2019.04.24.06.11.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Apr 2019 06:11:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) In-Reply-To: <127542bd-74a4-e4f4-e05b-ac16876a58ea@telia.com> Date: Wed, 24 Apr 2019 15:11:43 +0200 Cc: Nikita Popov , PHP internals Content-Transfer-Encoding: quoted-printable Message-ID: References: <127542bd-74a4-e4f4-e05b-ac16876a58ea@telia.com> To: =?utf-8?Q?Bj=C3=B6rn_Larsson?= X-Mailer: Apple Mail (2.3445.104.8) Subject: Re: [PHP-DEV] [RFC] Deprecate left-associative ternary operator From: claude.pache@gmail.com (Claude Pache) > Le 24 avr. 2019 =C3=A0 11:10, Bj=C3=B6rn Larsson = a =C3=A9crit : >=20 > Den 2019-04-22 kl. 10:09, skrev Nikita Popov: >> On Tue, Apr 9, 2019 at 11:54 AM Nikita Popov = wrote: >>=20 >>> Hi internals, >>> The only objection here came from Gabriel, and I don't think we'll = come to >>> an agreement. >>> Inspired by Bob's recent RFC for concat precedence, I'd like to = propose a >>> deprecation and removal of the left-associative behavior of = ternaries. >>> Instead, explicit parentheses should be used: >>>=20 >>> https://wiki.php.net/rfc/ternary_The only objection here came from >>> Gabriel, and I don't think we'll come to an agreement.associativity >>> >>>=20 >>> This RFC makes nested ternaries without disambiguating parentheses = an >>> error in PHP 8 -- we might want to consider making them = right-associative >>> instead, which is both useful and matches the behavior of other = languages. >>>=20 >>> Regards, >>> Nikita >>>=20 >> Heads up: Plan to start voting tomorrow. >>=20 >> Apart from Bishop, would anyone else prefer to directly go to right >> associativity in PHP 8 rather than making it an error? I'm rather = partial >> to that myself, maybe it can be included as a voting option... >>=20 >> Nikita >=20 > Hi, >=20 > I think one should go for the right associativity. 8.x is the right = place to > do it, if at all. Doing it directly in 8.0 has the benefit that when = upgrading > to a major version it justifies an upgrading project for an = application and > one also might get tool support, e.g. the php7mar tool for 7.0 was = quite > valuable. Also IDEs like phpstorm has good support. >=20 > One then has to weigh legacy code versus new code being written with a > behaviour different from almost all other languages. I'm not sure if = this > is an appropriate example to compare with, but I came to think on the > PHP 7.0 Uniform Variable Syntax rfc regarding migration effort and BC > impact. >=20 > r//Bj=C3=B6rn L >=20 > --=20 > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >=20 If you go for right-associative straight in PHP 8, you make it mandatory = to use a static analysis tool for: * migrating code from one major version to the next; * maintaining a library that aims to run in two major consecutive = versions. Although that might be a no-brainer for anyone following internals, I = doubt it is the case for anyone writing PHP. With a more step-wise approach (left-associative in PHP 7, = non-associative in PHP 8, right-associative in PHP 9 or 10), the = situation is much safer and simpler: you can=E2=80=99t even compile the = code in at least one of the consecutive major versions you aim to = support, and the error message says exactly what and where you have to = fix in order to make it working. As says an Italian proverb: chi va piano, va sano e lontano. =E2=80=94Claude