Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81115
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <90B1885A-E767-484E-8F38-A791E8A3FE9B@ajf.me>
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me>
	<90B1885A-E767-484E-8F38-A791E8A3FE9B@ajf.me>
Date: Sun, 25 Jan 2015 09:38:11 +0100
Message-ID: <CAB6YZuwQ7LQgrzT5-UeS0dCjznyvSy37uTniJQ--rVPzBKPZnw@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: pajousek@gmail.com (=?UTF-8?Q?Pavel_Kou=C5=99il?=)

On Sun, Jan 25, 2015 at 5:02 AM, Andrea Faulds <ajf@ajf.me> wrote:
> Hi everyone,
>
> Just a few small updates.
>
> I=E2=80=99ve made a small change to this RFC. Instead of the strict mode =
syntax being declare(strict_typehints=3DTRUE), it=E2=80=99s now declare(str=
ict_types=3D1) instead. This makes it a bit quicker to type - important giv=
en you=E2=80=99d need to type it a lot - without sacrificing much readabili=
ty. It also avoids using the words =E2=80=9Ctype hint=E2=80=9D, which I und=
erstand are contentious to some people.
>
> The patch now includes a more extensive set of tests: https://github.com/=
TazeTSchnitzel/php-src/tree/scalar_type_hints_2_strict_mode/Zend/tests/type=
hints/
>
> The pull request is also now green on Travis (aside from two failures on =
the debug build - but they also fail in master).
>
> Levi=E2=80=99s Return Types RFC has now passed, so now the RFC needs to c=
over that. The RFC currently doesn=E2=80=99t discuss return types, save for=
 a paragraph in the Future Scope section. When the return types patch is me=
rged, I=E2=80=99ll update the scalars patch, and then update the RFC. A poi=
nt of contention here is whether or not return types should always be stric=
t, or whether they should also obey the strict/weak modes. I=E2=80=99m not =
entirely sure on that one, that specific item may end up going to a vote. T=
hat said, I do lean towards always strict, given you can usually ensure you=
r return type=E2=80=99s correct.
>
> Thanks.
>
> --
> Andrea Faulds
> http://ajf.me/
>

Hello,

personally I still don't like this RFC in it's current form and
"shorter" declare won't change it. 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.

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.
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".

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.

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?

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 only ones I can think of right now are
basically int -> bool, int -> float, object (w/ __toString) -> string,
int -> string, float -> string?

Regards
Pavel Kouril