Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77183
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.218.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <8556C1E7-EDF3-47E2-9DA0-C9AB63DE56E6@ajf.me>
References: <6893A97A-EC4C-4124-B804-96E2A26B953F@ajf.me>
	<20140914000718.GB14312@phcomp.co.uk>
	<3177B936-50C1-4E5D-8687-FD235C72B411@ajf.me>
	<54153692.7050500@sugarcrm.com>
	<9CE963B0-E624-4267-BC2A-0F8D1F985DAE@ajf.me>
	<6f2236e18c61d30b247e1c6bb2de10f1@mail.gmail.com>
	<CAPhkiZxU0TQp1zJ5GcuhTFAaEhcYJ6Wg0cGyAnqYhY85id7Q5w@mail.gmail.com>
	<8556C1E7-EDF3-47E2-9DA0-C9AB63DE56E6@ajf.me>
Date: Sun, 14 Sep 2014 18:40:21 +0300
Message-ID: <CAPhkiZy5EMJRRef3Q4MnnQUe-ufVcwioCUa9rFmHy_JBKh5F3Q@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Zeev Suraski <zeev@zend.com>, Stas Malyshev <smalyshev@sugarcrm.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
From: narf@devilix.net (Andrey Andreev)

Hi,

On Sun, Sep 14, 2014 at 6:09 PM, Andrea Faulds <ajf@ajf.me> wrote:
>
> On 14 Sep 2014, at 15:56, Andrey Andreev <narf@devilix.net> wrote:
>
>> It seems a bit political ... A lot of people want either strict type
>> hints or type casting hints, but because the people on this list can't
>> get to agree on any of the two, this RFC tries to make a compromise
>> that, IMO, satisfies nobody. It's done not for the benefit of
>> everybody, but just so we can say that PHP has "scalar type hints".
>> I've said this in the RFC discussion thread: In order to satisfy both
>> sides, instead of arguing which is the one and true way, just
>> implement both.
>
> I=E2=80=99m not sure it satisfies nobody. I realise a lot of people would=
 prefer strict types, but plenty are still in favour of this as a compromis=
e:
>
> http://strawpoll.me/2463199/r - Might not be representative, but I held a=
 poll on Twitter and StackOverflow. There are the results. 67 would vote in=
 favour of strict hints (=C3=A0 la Hack), and 36 would vote in favour of th=
is RFC, with only 5 willing to vote against it, versus 10 voting against st=
rict hints. Note that the options aren=E2=80=99t mutually exclusive.

So, basically ... the poll shows nothing. :)
I was actually looking for that link (I took part in the poll), but
couldn't find it.

>> That is also why I suggested altering the proposed syntax here from:
>>
>>    function foo(int $bar)
>>
>> to:
>>
>>    function foo((int) $bar)
>
> But it=E2=80=99s not a cast. Such a syntax would be misleading. You would=
 reasonably expect the following two functions to be equivalent:
>
>     function foo($bar) { $bar =3D (int)$bar; }
>     function foo((int) $bar) { }
>
> Yet they are not equivalent at all.

They are not equivalent, because of the different rules that you're
proposing here, but it is a cast. And the fact that with this RFC
_both_ would mean some kind of cast is happening, is simply bad.

>> Whether it applies more strict rules or not, this RFC is clearly about
>> type _casting_ hints, while the used syntax has so far only been used
>> for strict type hints.
>
> Well, we haven=E2=80=99t had any scalar hints so far. It=E2=80=99s also w=
orth noting that the documentation for PHP uses this style even though inte=
rnal functions are not strict. Furthermore, scalar types in PHP are fundame=
ntally different from non-scalar types. We do not have weak typing for non-=
scalars: there are no implicit casts between non-scalar types. However, we =
implicitly convert and juggle the scalar types all the time.

... and I responded to this in the next paragraph. Userland doesn't
case about internal differences, that's why they're called internal
and why people outside of php-internals have for so long been puzzled
why we only have array and object type hints.

>> I know some would argue that this is a side
>> effect because you can't cast to a specific class type, but that's not
>> the point - the result is a strict type hint and that's what people
>> are used to. This is both inconsistent AND prevents PHP from having
>> strict scalar type hints in the future (because of the used syntax).
>
> Strict hints would still be possible with different syntax. However, I=E2=
=80=99m not sure they=E2=80=99re a good idea. Strict hints would be abandon=
ing PHP=E2=80=99s weakly-typed nature, and would segregate userland functio=
ns into two kinds: strict and non-strict. I also don=E2=80=99t expect that =
would pass internals anyway.

That's exactly what I'm talking about ... we already have a syntax for
strict typing, (and I want to put an emphais on this) *regardless of
the reasons why, we do have strict type hints*. I don't understand why
everybody is pretending that PHP doesn't have that feature just
because we're talking about scalars here.

Speaking strictly from a userland perspective, using that same syntax
for something different will be inconsistent and will cause confusion.
That another syntax could be used for strict typing in the future is
just not a serious thing to say.

As for the language's nature/philosophy/direction/whatever, I had
something written about that, but chose to discard it in order to
avoid that "discussion". Everybody is tired of talking about that.

> I don=E2=80=99t think permitting multiple options is really the way forwa=
rd, that sounds like the worst of both worlds.

You can't say it's the worst of both worlds when you have both worlds
in their entirety. And most importantly, they have always been two
separate worlds because they just don't make sense otherwise. I could
argue that this compromise RFC here is a mistake exactly because it is
trying to mix them.

Cheers,
Andrey.