Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81994
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.213.172 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <8703B53E-2C4A-4AC6-95C4-D4F19C6D5221@ajf.me>
References: <8703B53E-2C4A-4AC6-95C4-D4F19C6D5221@ajf.me>
Date: Fri, 6 Feb 2015 09:23:15 +0800
Message-ID: <CADajX4Dza_bu6AsiSEiWYCWgf9-4QJbUfKdmPP4NZnJ3iUBSMg@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] [VOTE] Scalar Type Hints
From: aharvey@php.net (Adam Harvey)

On 6 February 2015 at 04:14, Andrea Faulds <ajf@ajf.me> wrote:
> At long last, I=E2=80=99m going to put the RFC to a vote. It=E2=80=99s be=
en long enough - I don=E2=80=99t think there needs to be, or will be, much =
further discussion.

True, and I probably won't respond to any replies to this because we
don't need more noise, but I do want to explain my -1 vote. This is
long and rambling. I apologise. I've posted a formatted version of
this at https://gist.github.com/LawnGnome/354ca07f1799ff88fc35 in case
it's easier to read.

In no particular order, my issues with this RFC:

## The declare switch

Adding the cognitive overhead for each file for developers to have to
remember whether they have to cast a value before passing it to a
function or if PHP will automagically do that for them is a bad thing.
Of course, in a small, well compartmentalised file, or a single
developer code base, it wouldn't be a problem. Unfortunately, a lot of
PHP projects aren't that tidy. (Probably most of them, in fact.)

I also disagree with the comparisons that have been drawn on Internals
between `declare(strict_types=3D1)`, `use strict`, and `from __future__
import foo` statements. They're not the same thing at all:

* `use strict` is ultimately about code quality =E2=80=94 am I doing someth=
ing dumb?
* `from __future__ import foo` is ultimately about features =E2=80=94 yes, =
I
want to opt-in for the new shiny.
* `declare(strict_types=3D1)` isn't either of those, although it might
superficially appear so =E2=80=94 what it's really about is "I reject your
philosophy and substitute my own" in terms of typing.

There are structural decisions we can and should let our users make. I
believe this isn't one of them: allowing users to fundamentally change
the typing semantics of a language on a module-by-module level is, in
my opinion, insanity. Languages have to be opinionated about this sort
of issue: if they weren't, there'd only be one programming language
and it would have 800 switches to configure before you could write a
line of code. This sort of decision is the whole point of designing a
language: abdicating it by providing a switch is effectively us
shrugging and saying "sure, whatever, we don't care, so now we'll make
you care".

## Strong typing

This ties into the previous point: for scalars, PHP has never been a
strongly typed language. I was once on the train of strict typing
being universally better =E2=80=94 if you know that you always have an
integer, you never have to worry about a bad conversion, right? And,
if I was designing a language from scratch, I'd probably still feel
that way.

That language wouldn't be PHP, though. PHP is unapologetically weakly
typed from top to bottom. Designing a feature to break that would be
bad enough. Designing a feature to optionally break that is insidious.
If you care about whether the zval IS_STRING, you can check that
today. Encouraging our users to care goes against the entire
philosophy of the language.

To be clear: yes, we have problems in our type conversion matrix. The
fact that `"21 Jump Street" =3D=3D 21` is an issue (particularly because
it's silent), and we should be talking about that. But strong typing
is not the solution.

## Caller versus callee

Making the caller responsible for choosing the type behaviour is a
clever hack. (No pun intended, Facebookers.) I find the idea
intriguing from an academic perspective. Unfortunately, as with the
above point, this isn't consistent with PHP as a language that's
existed for 20 years and had type hinting in its current form for over
10 years. If we accept this, then we only widen the gap between scalar
values and array/object ones: for one set of type declarations, the
behaviour is determined entirely by the callee, and for another, it's
determined by both the callee (via the type hint) and the caller
(whether it will be converted or not).

## So what do we do for 7.0?

From where I sit, we had a good solution: it was the 0.1 version of
this RFC. It behaved like PHP should behave, respected PHP's long
standing scalar type handling and conversion rules, but most
importantly, it solved the **actual** problem scalar type hints are
supposed to solve in the simplest possible way:

    Can I guarantee that my function that expects an integer will
really get an integer?

I don't think that adding complexity on top of that helps anyone in
the long run. Yes, we get to tick some extra boxes =E2=80=94 "we support
strong typing", "we support weak typing", "we put the user in control"
=E2=80=94 but at the cost of having a language that not only supports, but
advertises multiple, inconsistent behaviours, requires users to be
aware of conversion minutiae that they shouldn't have to be mindful
of, and doesn't do anything to solve the actual problem above.

Adam