[VOTE][RFC] Coercive Scalar Type Hints

The proposed coercion rules aren't clear. The first table in the RFC
implies
that string is accepted for bool hints, and the second table says this
is
unchanged. But the examples section states that "foo" -> bool will raise
an
E_DEPRECATED error. I'm guessing this is a mistake, since you mentioned
above that string->bool is accepted.

You're right - that was an oversight when I updated the string->bool and
int->bool. Removed. Thanks!

You also stated above that false->bool is not supported (I'm guessing
you
meant float->bool). So users would be able to pass "4.3" to a bool
typehint,
but not 4.3? This behavior seems very arbitrary and confusing.

It may be confusing, but only academically so. Again, this approach tries
to work well with real world usage - and reject conversions which are
likely to be erroneous. "4.3" may look like a floating point number but
in the context of conversion to boolean, that doesn't matter much. It's a
string.

Not only would this RFC introduce backwards compatibility breaks in a
future
PHP release, but it still doesn't bring the same opportunities for
static
analysis which the optional strict mode in Anthony's proposal enables.

The coercive RFC misleadingly contradicts itself by stating that "we
don't
believe that is the case" "that Strict STH can help static analysis in
certain
cases" "although it's possible that Strict Typing may be able to help
static
analysis in certain edge cases." Do you believe it will help in certain
cases or
not?

I don't believe strict STH would bring any meaningful gains for static
analysis, no. Unlike the JIT/AOT advantages (on the same code) which I
believe I've proven cannot be gained, I can't prove this one - because you
can infer slightly different data from strict type hints. But again, in
edge cases. Such as:

function bar(float $x)
$foo = 1;
bar($foo); // will definitely fail in strict mode

Does it give you much? Not really.

Strict types can absolutely help - not only for static analysis, but
also for
potential future AOT/JIT development. Why? Because only types need to be
checked, rather than values.

I'm sorry, but that is simply wrong. Why? Because types ARE in fact a
part of the value in PHP. They're an element of PHP's value structure
(zval). You do NOT know the value with certainty until runtime, because
again, the type IS in fact a part of the value. The very same type
inference you can do with strict types you can do with coercive or even
with weak types. Again, this has been discussed in length in the threads
that took place several weeks ago. I believe even Anthony concluded that
for a given piece of code - assuming it's unchanged - there are no AOT/JIT
advantages. The theory is that there can be stronger static analysis,
which will provide more insightful suggestions to the developer to change
their code which will in turn result in code that can be JIT'd or AOT'd
better. Here too, we don't believe that's the case and believe you can
provide the same value with coercive type hints.

This is why an optional strict type system in

JavaScript makes it possible for Google to make "early and aggressive
optimisations" in V8 (see https://developers.google.com/v8/experiments).
It also makes it possible to catch errors earlier in development (see
the
example in my "A different user perspective on scalar type declarations"
email). As a developer of large enterprise applications, these benefits
are
very important to me.

I'm not saying that type hints don't make compile-time type inference
easier or more powerful. I am saying there's zero difference between
coercive type hints and strict type hints (and, also, that given we only
know the types with certainty right after the entry point to the function,
it gives you a lot less value than you might think - in both cases).
Please do see the lengthy threads we had on this subject a few weeks ago.

Static Analyzers need to be designed for Languages, rather than
Languages being designed for Static Analyzers.

You really have this backwards. Why do you think Facebook created Hack?
Why did Microsoft create TypeScript? Why are there serious discussions
to
add optional strict typing to ECMAScript proper?

I hardly think that static analyzers were the key reason for that at all,
but either way, that's my opinion. Again, note that I'm not arguing
there's zero advantage gained from adding type information to code - from
both reliability and performance perspectives. I am saying there's zero
difference on whether we coerce or error out in case we get a certain
value.

Zeev

-----Original Message-----
From: Theodore Brown [mailto:theodorejb@outlook.com]
Sent: Wednesday, March 11, 2015 11:01 PM
To: Zeev Suraski
Cc: internals@lists.php.net
Subject: RE: [VOTE][RFC] Coercive Scalar Type Hints

I don't believe strict STH would bring any meaningful gains for static
analysis, no. Unlike the JIT/AOT advantages (on the same code) which I
believe I've proven cannot be gained, I can't prove this one - because
you can infer slightly different data from strict type hints. But
again, in edge cases.

The benefits of strict typing for static analysis are hardly relegated
to edge
cases. Here's a simple example:

function getUserPermissions(int $userId): array function getUsername(int
$userId): string

$userId = 10;
$user = getUsername($userId);
$permissions = getUserPermissions($user);

In strict mode static analysis can tell you that this will fail, since a
string is
being passed to a function expecting an int. With coercive STH, all you
know
is that it may or may not work.

That's correct, but that's not the kind of edge case I was talking about.
When seeing a string being passed to an integer type hint, with coercive
STH, your static analysis tool can employ an identical rule but instead of
saying it WILL fail, it can tell you it may fail. You can then decide
what you want to do about that knowledge, and cast explicitly if you want
to - which you would probably do in the strict STH case.

Yes, with strict STH you'd know that more things fail during static
analysis time, because, well, it fails a lot more cases. What's the
remedy? Typically it would be forcing the type using an explicit cast,
which is worse across the board than a dynamic cast. It's also not any
faster in terms of JIT - the casting code is pretty much identical to the
coercion code. But the bigger question is, do you WANT that to fail? Or
is it noise that the language should be dealing with automatically? For
20 years, the answer has been the latter, and even though it became a bit
of a sport to look down at PHP's dynamic typing, it seems to have worked
out pretty well for it in terms of popularity and ecosystem.

Of course you can do the same type inference. The difference is that
with
coercive STH knowing the type isn't enough - you also have to know the
value. A string passed to a function with an int type declaration MAY
succeed
or MAY fail. You won't know until the value is checked at runtime.
However, in strict mode a user would be required to pass a value of the
correct type. There are many cases where PHP can check the types at
compile time, but not the values. Therefore, with strict STH it is
possible to
eliminate many runtime value checks and type conversions. For example:

You can't eliminate anything unless you force the developer to change the
code. These changes would typically be some sort of explicit type
enforcement, smart (which we don't yet have) or dumb - but those
conversions contain code that is pretty much identical to the checks
weak/coercive types do.

So again, it boils down to this:

1. If you have the types in the right form, static analysis yields
   identical results between coercive & strict (it will give you thumbs up in
   both cases).
2. If you don't have the right types, strict analysis will outright reject
   it - sensible or not. Assuming that semantically you do want that to work

• you'd have to add a type conversion - which would result in code that
  performs pretty much identically to a weak type hint.

-> no gain.

This too was in the thread from a few weeks ago in a lot more detail.

function getFooByVal(string $val): string function getBarByFoo(int $foo)
getBarByFoo(getFooByVal("value"));

With coercive STH a runtime value check is necessary. With strict types,
a
failure could be detected at compile time, the user would fix their
code, and
at runtime no value check is necessary. This is a huge advantage for
AOT/JIT.

It's a third example of the same thing. Yes, strict type hints fail a lot
more cases, and yes, it can be detected in compile time in some cases -
much like coercive STH could detect these very same cases and tell you
they may fail. There's nothing new in your examples that wasn't brought
up back in that thread.

Thanks,

Zeev