On Tue, Feb 17, 2015 at 5:38 PM, Sara Golemon <poll...@php.net> wrote:
> On Tue, Feb 17, 2015 at 12:22 AM, Rasmus Lerdorf <ras...@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 > >
