Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82934
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain lerdorf.com designates 209.85.220.46 as permitted sender)
Message-ID: <54E2FA57.6050009@lerdorf.com>
Date: Tue, 17 Feb 2015 00:22:47 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Sara Golemon <pollita@php.net>
CC: francois@php.net, Philip Sturgeon <pjsturgeon@gmail.com>, 
 Arvids Godjuks <arvids.godjuks@gmail.com>,
 Jefferson Gonzalez <jgmdev@gmail.com>, 
 Rowan Collins <rowan.collins@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <011801d04a07$83ab1c00$8b015400$@php.net>	<CABDNdAFQsbo-A-gijPCwYDOf3ts-yKpP0tAL--WUaLU26GB-AQ@mail.gmail.com>	<016f01d04a3a$e9183220$bb489660$@php.net>	<CAESVnVoM7YbmXA8hTG1O66j+6YX3Xx2Q3uj_F=TPjHA4ws=8JA@mail.gmail.com>	<54E290E5.3020508@lerdorf.com>	<CAESVnVpXmmfDh6iqT=n27iHQ21_QxPWkez_=bEc1Dpn+MNrjMg@mail.gmail.com>	<54E2AD88.6040206@lerdorf.com> <CAESVnVoFD7-A2_a1ZPR9av2tiVbbs7D0NUt0TihH-dQFvhkH6Q@mail.gmail.com>
In-Reply-To: <CAESVnVoFD7-A2_a1ZPR9av2tiVbbs7D0NUt0TihH-dQFvhkH6Q@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="0H8cIulkKaMuPnIk0DDo1WHttTFOHvADE"
Subject: Re: [PHP-DEV] Reviving scalar type hints
From: rasmus@lerdorf.com (Rasmus Lerdorf)

--0H8cIulkKaMuPnIk0DDo1WHttTFOHvADE
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 02/16/2015 09:48 PM, Sara Golemon wrote:
> Second, I should clarify that while the HHVM runtime performs
> coersion, the hack type checker is strict.  So my original statement
> was inaccurate.  As far as hack is concerned, it's simply strict.
> Period.

With both the default (partial) type checking and strict enabled, my
number_format() example in Hack produces:

int(1000)
1,000

string(4) "1000"
1,000

float(1000)
1,000

string(5) "1000 "
Warning: number_format() expects parameter 1 to be double, string given

string(5) " 1000"
1,000

string(9) "1000 dogs"
Warning: number_format() expects parameter 1 to be double, string given

string(3) "dog"
Warning: number_format() expects parameter 1 to be double, string given

resource(4) of type (stream)
Warning: number_format() expects parameter 1 to be double, resource given=



Basically it accepts, ints, floats and well-formed numeric strings and
the hh_client type checker is telling me I have "No errors". So the only
difference between Hack's strict mode and the current coercive behaviour
in PHP is strings with trailing chars. The "1000 dogs" case. "1000 " as
well in my example, but that is the same case. Where in PHP you get a
notice but it still does the conversion and in Hack you get a warning
and the conversion isn't done. So even though Hack has both a "partial"
type checking mode and a "strict" mode, the decision was to still do
type coercion for the others. I kind of expected it to only accept a
float in full-on strict mode to mimic the no-compromise strictness
proposed in the RFC.

Also, looking through the code, I really don't see this "simply strict"
anywhere when it comes to calling internal functions. For example:

    $a =3D [1,2,3,4,5];
    print_r(array_reverse($a,"0"));

It doesn't complain that "0" is a string and not a boolean. It doesn't
even complain about "dog" there.

And the one everyone gets uppity about. bool->int conversion in
curl_setopt(). eg.

    $ch =3D curl_init("https://74.125.28.104");
    curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, true);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    echo curl_exec($ch);
    echo curl_error($ch);

PHP obviously converts true to 1 there which has been a problem because
what people really meant was to set it to 2. We spew a notice for this,
of course:

Notice: curl_setopt(): CURLOPT_SSL_VERIFYHOST with value 1 is deprecated
and will be removed as of libcurl 7.28.1. It is recommended to use value
2 instead in ...

In Hack it appears that true is also converted to 1 in <?hh // strict
mode and no notice appears and the hh_client type checker doesn't
complain. If instead of true I pass in an array of strings, it still
converts it to 1 even though the type is blatantly wrong. It looks like
it was kept quite loose to match PHP and not cause too much legacy code
to break. In this particular case it is pretty dangerous to be
completely silent about it though since it actually means no host
verification is getting done. The output when properly set to 2 from
both PHP and Hack is:

SSL: certificate subject name 'www.google.com' does not match target
host name '74.125.28.104'

Please correct me here if I somehow ran these incorrectly. I did put
some deliberate type errors into my userspace code and hh_client caught
those nicely, so it seems like it was working, but it didn't catch
anything when it came to calling the internal API functions.

eg.

<?hh // strict
function test() : int {
    $ch =3D curl_init("https://74.125.28.104");
    curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, ["I have no idea what I am
doing"]);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    echo curl_exec($ch);
    echo curl_error($ch);
    return "beer";
}

hh_client reports:
/home/rasmus/test/a.php:8:12,17: Invalid return type (Typing[4110])
  /home/rasmus/test/a.php:2:19,21: This is an int
  /home/rasmus/test/a.php:8:12,17: It is incompatible with a string

When I change return "beer" to return 1 hh_client is happy.

So, you keep asking what I would support. I would like to see an RFC
along the following lines:

1. Tighten up the type coercion for the "1000 dogs" case although we
   have to look at whether there is a problem with some database APIs
   returning space-padded fields so "1000    " would now break.
   Hopefully that is fringe enough to not break the world.

2a. In strict mode, tone down the strictness and allow non-lossy
    coercion including int->float. And yes, I know in really edge cases
    that isn't technically non-lossy, but for all practical purposes it
    is.

or

2b. A much more flexible system for specifying multiple types. I should
    be able to say that my function takes something that looks like a
    number if I choose and still take advantage of stricter typing for
    other parameters.

3. Don't turn on crazy-strict mode for internal functions that weren't
   designed for that. Instead provide the same ability as userspace gets
   for developers to gradually design their APIs to be stricter if they
   so desire allowing both Hack and PHP to implement a stricter
   curl_setopt(), for example.

-Rasmus


--0H8cIulkKaMuPnIk0DDo1WHttTFOHvADE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlTi+lcACgkQlxayKTuqOuD2egCghEnSAkhCK1UPZSM4uZ1ZT5Bq
QroAn0oueCe3aiabjRN40THx3OM33RS1
=/CA9
-----END PGP SIGNATURE-----

--0H8cIulkKaMuPnIk0DDo1WHttTFOHvADE--