Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82988
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain beberlei.de from 209.85.212.181 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAESVnVqjGJS8rJaYyrEkX-Y6KCaM=e+z9xEYyH9A7NkgYO0YAw@mail.gmail.com>
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>
	<54E2FA57.6050009@lerdorf.com>
	<CAESVnVqjGJS8rJaYyrEkX-Y6KCaM=e+z9xEYyH9A7NkgYO0YAw@mail.gmail.com>
Date: Tue, 17 Feb 2015 17:59:23 +0100
Message-ID: <CAEPJdunQO7M6-q5D9mJfq93++8OChQxwpuiTureXtpAuy9Tw1w@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Rasmus Lerdorf <rasmus@lerdorf.com>, 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>
Content-Type: multipart/alternative; boundary=089e01419d1ce98952050f4b9fb6
Subject: Re: [PHP-DEV] Reviving scalar type hints
From: kontakt@beberlei.de (Benjamin Eberlei)

--089e01419d1ce98952050f4b9fb6
Content-Type: text/plain; charset=UTF-8

On Tue, Feb 17, 2015 at 5:38 PM, Sara Golemon <pollita@php.net> wrote:

> On Tue, Feb 17, 2015 at 12:22 AM, Rasmus Lerdorf <rasmus@lerdorf.com>
> wrote:
> > 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:
> >
> > ...
> >
> > 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.
> >
> The mechanisms are strict, but the definitions, in hack, are untyped,
> so there's nothing to validate:
>
> hphp/hack/hhi/stdlib/builtins_string.hhi:
>   function number_format($number, $decimals = 0, $dec_point = ".",
> $thousands_sep = ",");
>
> We left a lot of stuff untyped from hack's point of view precisely
> because so much of PHP's APIs are non-sensical.  Have you looked at
> what chr() does with bad types lately? Yikes.
>

Wait, so Hack is actually only treating userland functions strict (and
maybe the occasional internal function).

This approach would immediately fix all the number_format, sin, tan
problems, but again be rejected
by static propononets for not being complete for analysis. We can run this
circle for another time :-)

>
> > 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.
> >
> Hopefully, though I think that we could embrace the idea of trailing
> space as insignificant.
>
> > 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.
> >
> Nod. Ze'ev called for this too.
>
> > 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.
> >
> Union types.  I'm hear a lot of support for this concept, and not
> exclusively from one camp.
> Perhaps with a psuedo-type defined somewhere to account for the
> half-type "numeric string".
>
> > 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.
> >
> Perhaps a ZEND_ACC_STRICT flag which lets an API opt-in to strict mode?
> Or something passed to the arg_info struct? The details are secondary,
> but you get my meaning...
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--089e01419d1ce98952050f4b9fb6--