Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81128
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <CAB6YZuwQ7LQgrzT5-UeS0dCjznyvSy37uTniJQ--rVPzBKPZnw@mail.gmail.com>
Date: Sun, 25 Jan 2015 16:05:15 +0000
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <5893FBAE-EA06-4E06-9E6C-02D4C08C0BCB@ajf.me>
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me> <90B1885A-E767-484E-8F38-A791E8A3FE9B@ajf.me> <CAB6YZuwQ7LQgrzT5-UeS0dCjznyvSy37uTniJQ--rVPzBKPZnw@mail.gmail.com>
To: =?utf-8?Q?Pavel_Kou=C5=99il?= <pajousek@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: ajf@ajf.me (Andrea Faulds)

Hi Pavel,

> On 25 Jan 2015, at 08:38, Pavel Kou=C5=99il <pajousek@gmail.com> =
wrote:
>=20
> personally I still don't like this RFC in it's current form and
> "shorter" declare won't change it.

I didn=E2=80=99t expect that making it shorter would really change =
anyone=E2=80=99s opinions, except perhaps those who don=E2=80=99t like =
the term =E2=80=9Ctype hint=E2=80=9D.

> I was thinking a lot about the
> typehints in PHP for last few days and I think having only one way
> would be the best - and it's somewhere between the curent weak and
> strict typing. My main "issue" is that the current weak typing is too
> loose and the strict typing is too strict.
>=20
> The problem with the current strict typing is that you cannot pass
> "int" to a "float" parameter, even though there can be a totally
> lossless conversion and it works in other strongly typed languages.

It can *sometimes* be a lossless conversion. Only sometimes.

For float to int conversion:

* Floats have the special values INF, NAN and -NAN, which cannot be =
preserved
* Floats have negative zero, which also cannot be preserved
* Fractional components cannot be preserved
* Floats sacrifice precision to allow a wider range of values. They work =
with significant figures (scientific notation), unlike integers which =
always offer full precision. So a particular float value isn=E2=80=99t =
necessarily equivalent to a particular integer value, you have to invent =
precision to do the conversion. 2e10 is dealt with as if it=E2=80=99s 2 =
with 10 zeroes after it, but it=E2=80=99s just a number beginning with 2 =
that has a magnitude of roughly 10^10. If you convert it to the integer =
value 20 000 000 000, you=E2=80=99ve just invented values for those =
trailing digits - those digits weren=E2=80=99t necessarily zero, we just =
don=E2=80=99t know what those digits are. Someone who=E2=80=99s an =
expert on floating-point might need to correct me here, but I think this =
is correct to some extent. What I=E2=80=99m saying is that =
float->integer conversion is inherently imprecise.

For int to float conversion:

* Values beyond 2^53 or below -2^53 cannot be represented as floats =
without a loss of precision

Some strongly-typed languages allow these conversions implicitly, but =
I=E2=80=99m not sure that=E2=80=99s a good thing or something we should =
want to copy. Loss of precision isn=E2=80=99t good. If you ask for =
strict typing, you probably want to avoid it, and should get strict =
typing.

> And being able to pass a float(1.5) to int and lose the 0.5 value
> doesn't make sense as well, because data will get lost. Neither of
> those feels somehow "predictable" and "natural=E2=80=9D.

Sure, but it is our existing behaviour.

> Also, after a little bit of thinking, if someone needs to do a type
> conversion while calling a method, writing foo((int) $bar) isn't that
> hard.

This isn=E2=80=99t a good idea. Explicit casts do not care for what =
value you give them, they will convert whether or not the conversion =
makes sense.

Unfortunately we don=E2=80=99t have safe casting functions because they =
were rejected. Alas.

> So, I think it would be best to choose just one of these two
> approaches and either loosen it a little or make it more strict (so
> data loss doesn't happen). But I guess this approach would be
> inconsistent with how the built-in PHP functions work?

While it never went to a vote, the Scalar Type Hinting with Casts RFC, =
which proposed stricter weak casts, was not well-received. The Safe =
Casting Functions RFC was rejected when it went to a vote.

> PS: Ideally, the data loss rules should be made for types and not
> values (like the old scalar type hints RFC had), so you don't get
> unpredictable results.

The Scalar Type Hinting with Casts RFC didn=E2=80=99t do that, it was =
also based on values.

In a dynamically-typed language like PHP, I don=E2=80=99t see why it =
needs to be type-based rather than value-based.

Thanks.

--
Andrea Faulds
http://ajf.me/