[VOTE] Scalar Type Hints

With that said, there's nothing stopping you from putting up your time to
create a competing proposal and patch. If you really believe that weak
types
are the better way forward, why not codify that? If only one of the RFCs
passes, then you have your answer. If both pass, we can simply have
another
vote to choose which to move forward with.
Competition is healthy for the community.

That may be a good idea.

You also said earlier in the thread that you don't agree with the points
that I
made on my blog post (http://blog.ircmaxell.com/2015/02/scalar-types-and-
php.html). Can you share what you don't agree with (in the comments or
this
thread)?
Rasmus posted some issues, most of which I consider details in this
proposal
(declare() and lack of handling the int->float conversion
case) and I replied to them (I think they are handleable). If you have
other
disagreement, why not share?

I've shared them countless times over the past decade.
Strict typing exposes data that should not be interesting in the vast
majority of cases and makes it prominently available for handling using
native syntax. That's bound to make a lot more developers care about the
internal type of scalars, and rely a lot less on PHP's dynamic typing - or,
in other words, make PHP a more complex language. While Andrea's RFC does a
significantly better job at hiding strict typing from uninterested parties,
ultimately, mostly everyone will bump into it and have to accustom
themselves to a typing behavior that's never ever existed in PHP. Two
examples that come to mind are people working on shared code (not exactly an
uncommon occurrence) and variables that find their way into internal
strictly-typed calls, which would result in obscure messages for someone
that's used to "32" and 32 to be virtually identical in PHP.

I would especially would like a response to the point that I made where I
showed 3 examples where weak hints of any type would cause subtle and
hard-to-find bugs; one of which was a high-level security risk.

Languages have advantages and disadvantages. PHP's biggest advantages is
developer productivity, and dynamic typing is a big component of that. Does
it have disadvantages? Sure. But PHP was designed with the belief that the
advantages of dynamic typing outweighs that of strict typing. In the few
cases where strict type checking is needed, you have the facilities to do
that in a bit of custom code. That balance of making strict type checks
possible - but not at the level of native constructs - is the right balance
for a dynamically typed language like PHP. You'd only add strict type
checking if it's really needed, and not as an afterthought.

To your examples, I'm not at all advocating the use of an arm's race to put
typing information - weak or strict - everywhere. Of course, if you place a
weak type hint in a situation where type conversion would pose a high
security weak, it's a mistake. Keep the handling in custom code in such
cases. In most scenarios, however, that's not the case. And in even more
scenarios - there's no need for any kind of scalar type hinting at all.

One final side-point: In my work on Recki-CT, I learned very early on that
casts are quite expensive. When compiling mandel() from Zend/bench.php,
the implicit casts that were happening on $w2, $x and a few other vars
(which were ints) to floats for the computation added approximately 10% to
the runtime of the function. The casts in mandel2 accounted for 20% of the
runtime. Let me say that again: the
int->float conversion in the loops accounted for between 10% and 20%
of the function call. And that's not a dynamic cast (a branch based on
type),
it's a single fild instruction. Having the ability to statically know
that a cast
will never be needed can result in significantly faster (and easier)
native code
generation...

Two points on this one:

1. PHP's motto has always been developer productivity over performance,

That makes my day. And I will leep this quote in mind for any future
discussions about new additions.

if
squeezing performance meant bothering the developer with implementation
details he shouldn't care about. We prefer to work hard on getting the
engine optimized, and let the developer focus on creating the business logic
in the simplest possible way. By the way, in this particular case, it's
possible to automatically detect that the variables in question are all
floats, and have the engine automatically do it for you. It's not easy, but
can be done. If we ever have JIT in PHP, it will do that automatically for
developers - which is exactly PHP's spirit.

And it will still be possible with this RFC. And this RFC allows
better and more efficient way for strict areas, especially for
functions/methods calls.

2. More importantly to our discussion, there's zero practical difference in
   terms of performance implications between weak and strict typing.

Everyone forming their opinion regarding weak vs. strict vs. both should
know there's no performance impact to be expected from any choice we make.

And it is not about performance, never was and should never be.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

Zeev,

With that said, there's nothing stopping you from putting up your time to
create a competing proposal and patch. If you really believe that weak
types
are the better way forward, why not codify that? If only one of the RFCs
passes, then you have your answer. If both pass, we can simply have
another
vote to choose which to move forward with.
Competition is healthy for the community.

That may be a good idea.

You also said earlier in the thread that you don't agree with the points
that I
made on my blog post (http://blog.ircmaxell.com/2015/02/scalar-types-and-
php.html). Can you share what you don't agree with (in the comments or
this
thread)?
Rasmus posted some issues, most of which I consider details in this
proposal
(declare() and lack of handling the int->float conversion
case) and I replied to them (I think they are handleable). If you have
other
disagreement, why not share?

I've shared them countless times over the past decade.

You said you disagreed with my post (meaning claims I made). I didn't
ask why you didn't like strict typing, I asked specifically why you
disagreed with the post.

Strict typing exposes data that should not be interesting in the vast
majority of cases and makes it prominently available for handling using

It's data you don't think is interesting. Obviously 68% of voters
right now think it's interesting enough to support it.

native syntax. That's bound to make a lot more developers care about the
internal type of scalars, and rely a lot less on PHP's dynamic typing - or,
in other words, make PHP a more complex language. While Andrea's RFC does a
significantly better job at hiding strict typing from uninterested parties,
ultimately, mostly everyone will bump into it and have to accustom
themselves to a typing behavior that's never ever existed in PHP. Two
examples that come to mind are people working on shared code (not exactly an
uncommon occurrence) and variables that find their way into internal
strictly-typed calls, which would result in obscure messages for someone
that's used to "32" and 32 to be virtually identical in PHP.

The problem is not "32" and 32. The problem is "apple" and 32. A value
may work, but we're not talking about values, we're talking about
types. And yes, in some spots and in a lot of cases having values
auto-convert is amazing. And is one of the greatest powers of PHP as a
language. But in many cases it leads to subtle bugs. In many cases it
leads to code that's REALLY hard to reason about ahead of time.

There's a reason we don't see many static analyzers for PHP. I wrote
one, and I can tell you that it only works by eliminating mixed types
(if it's mixed, it gives up). You can't do it for mixed types in PHP
simply because the analysis depends on values not present in the code
at compile time.

Yet static analyzers are incredibly useful for finding bugs. And
making it easier to work on shared code since they know if they make a
breaking change, they'll be told about it. That's why the VAST
majority of large codebases (> 1 million lines of code) are written
using typed languages (and many of those not are moving in that
direction). Because the benefits of typing on large scale teams isn't
something of debate anymore.

I would especially would like a response to the point that I made where I
showed 3 examples where weak hints of any type would cause subtle and
hard-to-find bugs; one of which was a high-level security risk.

Languages have advantages and disadvantages. PHP's biggest advantages is
developer productivity, and dynamic typing is a big component of that. Does
it have disadvantages? Sure. But PHP was designed with the belief that the
advantages of dynamic typing outweighs that of strict typing. In the few
cases where strict type checking is needed, you have the facilities to do
that in a bit of custom code. That balance of making strict type checks
possible - but not at the level of native constructs - is the right balance
for a dynamically typed language like PHP. You'd only add strict type
checking if it's really needed, and not as an afterthought.

Which is why many of us want it in PHP. So we can switch back and
forth, having the parts of the application that make sense to be fully
typed, fully typed and the parts that don't, well, not.

In fact, this proposal, including the strict component, embraces PHP's
dynamic nature. It simply extends what existing in 5.0 for classes to
the rest of the type system. But it gives the developer the choice. It
gives the developer the power.

Is that, after all, what PHP is all about? Empowering people?

To your examples, I'm not at all advocating the use of an arm's race to put
typing information - weak or strict - everywhere. Of course, if you place a
weak type hint in a situation where type conversion would pose a high
security weak, it's a mistake. Keep the handling in custom code in such
cases. In most scenarios, however, that's not the case. And in even more
scenarios - there's no need for any kind of scalar type hinting at all.

I just want to point out that this code already exists today. Meaning
that the code you said shouldn't exist has been live for years.

https://github.com/search?p=4&q=%22curl_setopt%28%24ch%2C+CURLOPT_SSL_VERIFYHOST%2C+true%29%3B%22&ref=searchresults&type=Code&utf8=%E2%9C%93

This is only caught by new versions of CURL which removed option 1:
https://github.com/php/php-src/blob/master/ext/curl/tests/bug63363.phpt

So I get where you're saying "keep the handling in custom code",
except that's not what happens. Not even in our own code base. Yet
alone in other's.

One final side-point: In my work on Recki-CT, I learned very early on that
casts are quite expensive. When compiling mandel() from Zend/bench.php,
the implicit casts that were happening on $w2, $x and a few other vars
(which were ints) to floats for the computation added approximately 10% to
the runtime of the function. The casts in mandel2 accounted for 20% of the
runtime. Let me say that again: the
int->float conversion in the loops accounted for between 10% and 20%
of the function call. And that's not a dynamic cast (a branch based on
type),
it's a single fild instruction. Having the ability to statically know
that a cast
will never be needed can result in significantly faster (and easier)
native code
generation...

Two points on this one:

1. PHP's motto has always been developer productivity over performance, if
   squeezing performance meant bothering the developer with implementation
   details he shouldn't care about. We prefer to work hard on getting the
   engine optimized, and let the developer focus on creating the business logic
   in the simplest possible way. By the way, in this particular case, it's
   possible to automatically detect that the variables in question are all
   floats, and have the engine automatically do it for you. It's not easy, but
   can be done. If we ever have JIT in PHP, it will do that automatically for
   developers - which is exactly PHP's spirit.
2. More importantly to our discussion, there's zero practical difference in
   terms of performance implications between weak and strict typing. Inside
   the function code, you can rely in exactly the same way - with absolute
   confidence that you got what you asked for. In the calling code - you can't
   assume anything about the value being passed and must conduct checks into
   it - unless it too came from a type-hinted argument and you actually tracked
   that it's not being touched anywhere in the function code (which may result
   in its type being altered). Then too - it doesn't matter if it came from a
   weak type hint or a strict one. The result is identical if your function
   was reached. The only difference is that in weak types there'll be
   auto-conversion if needed - but unlike the pure-variable-juggling code in
   mandel(), in such a case - the conversion will be negligible compared to the
   function call overhead, and potentially even the extra type checking code
   you'd add.

Everyone forming their opinion regarding weak vs. strict vs. both should
know there's no performance impact to be expected from any choice we make.

That wasn't the intent of that side-note. I wasn't trying to say that
strict is faster. I was simply trying to share a point that when you
care about generating native code (as I do), then there are
differences between weak-scalar and strong-scalar. I believe it was
you (could have been someone else) who said that to a JIT/AOT compiler
it didn't matter. And I was just trying to point out that's not really
true.

Thanks,

Anthony

Hi Anthony,

If you are working on JIT, you should understand that declare() switch to
strict typing can't improve anything, because it works on caller side and
in each function you now will have to generate code for both weak and
strict checks.

Why do these checks have to be generated in the function, instead of
performing checks/casts at the call-site? Naively I would assume this to
perform better, because you can make use of type-information around the
call-site to elide checks/casts. Or does this have adverse effects due to
larger code size or something like that?

Nikita

Dmitry,

Hi Anthony,

If you are working on JIT, you should understand that declare() switch to
strict typing can't improve anything, because it works on caller side and in
each function you now will have to generate code for both weak and strict
checks.

Well, if you know the destination function at compile time, you don't
need to generate generic code. you can generate a direct dispatch
(asm-level function call). In this case, strict lets you push type
checks back to compile time, where in non-strict mode you still need
to generation runtime conversion logic. That runtime conversion logic
then requires the ability to hook into Zend's error handling
mechanism, vastly complicating the generated code (and the generating
code).

In fact, the research I have been doing is precisely around that
(where I know for a fact that all remaining function calls are going
to be typed, and compile the entire block at one time with direct
calls). So that way I never need to actually do even as much as a FCC
to call a userland function. Which then lets me avoid generating
typing code (since I know the types). Which is why I'm advocating for
strict, since that way we can treat an entire graph of function calls
as strict and compile them all in one go (no need to even JIT at
runtime, just compile AOT).

If your research has shown something different, care to share?

According to mandel() and integer to float conversion in the loop, it's
possible to perform a backward data-propagation pass to catch this case and
replace integer by float in first place. We did it in our old JIT prototypes
without any type hinting. Also, don't use "fild", use SSE2 and/or AVX.

I did wind up doing a few passes to back-propagate the cast (among
other optimizations). But it's still a point that the conversions
aren't exactly cheap. But as I said before, that was a side-note and
not really an argument for/against strict typing. So worth mentioning,
but shouldn't affect anyone's decision.

Re fild vs SSE/AVX: that was up to the backend code generator we were
using (libjit). It may be an open req against that lib to generate the
different instruction, or perhaps it just failed a heuristic. We were
working a level higher than the generated ASM, so not really 100% sure
why it made that decision.

Anthony