Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103669
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=q5TdTXtv9fn/ClW0kfhJ6q1tn1jMEAZWijgOGQclw/rXvThpq9JkQh2O0jdggE
	OX8dNWOoUjKs1twOA98JuPMEjOO/vlsXNUfHbH1Ynv0P2QjS5ziyy747rt+s7dPt
	BMBV6va62NaAdQ8xtIqpeP11dNGfPb2MafhgpffKxpJag=;
MIME-Version: 1.0
References: <a7761c2f-5716-279b-d701-5f588b856277@gmx.de> <dbfae3d5-e317-f680-9fe6-240ab142d105@gmail.com> <94f5feb8-6589-3a0a-2849-7679cec1858c@gmx.de> <a0e50789-10c0-263d-f6a7-56486d7bb318@gmail.com> <CAF+90c-2ama6LBDY0xQKN1oPV-YMaY2==SSWk_hSstc40y9NWQ@mail.gmail.com> <CAJHtznzzBvx9Dc5YPGT6kU97doCj0O2FxGGjnTNh4Pv2-Pucxg@mail.gmail.com> <CAF+90c_i7802QYeBUkgyc81Yv2ASzSHYqxNrObcA+TxA_b_46A@mail.gmail.com>
In-Reply-To: <CAF+90c_i7802QYeBUkgyc81Yv2ASzSHYqxNrObcA+TxA_b_46A@mail.gmail.com>
Date: Wed, 2 Jan 2019 19:22:40 +0200
Message-ID: <CAJHtznwkU5nt3hPrE7f8X+cND3F6OMxTaFGBUZ6=Of_+rB0tsQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, "Christoph M. Becker" <cmbecker69@gmx.de>,  PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004e4885057e7ce55d"
Subject: Re: [PHP-DEV] Inconsistent float to string vs. string to floatcasting
From: zeev@php.net (Zeev Suraski)

--0000000000004e4885057e7ce55d
Content-Type: text/plain; charset="UTF-8"

On Wed, Jan 2, 2019 at 6:11 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Wed, Jan 2, 2019 at 12:33 PM Zeev Suraski <zeev@php.net> wrote:
> I don't expect this to be a particularly large issue for two reasons:
>
> 1. Not many people use this. I'm sure that there *are* people who use this
> and use it intentionally, but I've only ever seen reference to this issue
> as a bug or a gotcha.
> 2. Even if somebody is using this functionality, the only thing that's
> going to happen is that their number display switches from 1,5 to 1.5.
> That's a minor UX regression, not a broken application. It's something that
> will have to be fixed, but it's also not critical, and for a legacy
> application one might even not bother.
>

FWIW, neither of these are very convincing for me:
1. I'm not sure what you mean "not many people use this"?  People don't
convert floats to strings?
2. Perhaps you meant they weren't proactively relying on this behavior,
which could be true - but it doesn't matter whether people were expecting
or otherwise desiring this behavior when they wrote the code.  Whatever the
current behavior is - they adjusted for it, and ended up using it,
consequently relying on it.
3. I view a UX change as a big deal.  As we should in a language that is
very commonly used to create UI.
4. This could effect not only UX, but also integration code.  You could
have PHP output feeding into something else - and suddenly, the format
breaks.  With the fix HAVING to be in the other side, no less.

I fail to understand how we could consider changing such a fundamental
element (to-string behavior of floats) without an in-depth discussion.  We
mustn't.

I think we should just put this to an RFC vote. We regularly have these
> types of discussions, and people just disagree about level of anticipated
> BC break relative to benefit of the change.
>

The point of an RFC is, in fact, to have these discussions.  This is what
we're doing right now.  This is what the RFC process is all about - not the
vote.  It sounds to me as if you're saying "what's the point of discussing,
let's just vote" (waiting out the two weeks as needed), with which I would
wholeheartedly disagree.  Apologies if you meant something else.

Zeev

--0000000000004e4885057e7ce55d--