Zeev et al,
>> 2. It is not not about being lossless or not. People expect bool -> int to
>> be
>> disabled, for example, and it is not lossless.
>>
>> 3. It is more a question of finding a consensus about conversions which
>> don't
>> make sense, and disabling them. Examples include bool conversion to any
>> other type and, of course, disabling trailing chars in numeric strings.
>
> I agree. It's more of a question of eliminating potentially dangerous
> conversions than just being lossless.
Disagree. For a weak-mode, that does solve the problems that many
people want solved. But it also ignores a lot of the problems that the
strict crowd want solved.
Let me show by example:
function convertToInt(string $number): int {
if (!preg_match("(^[0-9]{1,17}$)", $number)) {
throw new InvalidArgumentException("Supplied argument is not a
valid number");
}
return $number;
}
>From a weak standpoint that looks like it should work. And from a
pragmatic standpoint it should work as well. But from a static
analysis standpoint, we can't tell.
A static analyzer (one of the reasons people want strict) would error
there. The reason is that *at compile time* it can't reason about the
code well enough to determine if there's an error or not. You're
passing a string where you expect an int. Is that going to work? We
don't know. So the analyzer would need to throw a warning that the
cast is potentially unsafe because it can't guarantee that the runtime
won't throw an error. Which means that to remove the warning you'd
need to add an explicit cast.
At which point what does the weak mode buy us?
Instead, if we make the strict mode behave based on types alone, this
wouldn't be a problem (because we can detect ahead of time to 100%
accuracy type errors in the strict mode files). And hence prevent
errors at build time, rather than detecting them at runtime in prod.
> associated, built collectively over the last two decades. As Rasmus
> demonstrated, flipping that switch on for built-in functions results in a
> lot of work to 'clean' the code up, but you end up with having code that's
> not necessarily any better. That said, it's quite possible that the
> situation will be much improved if & when we implement the less-strict rules
> we're proposing here, which would accept "32" as an integer or 37 as a
> float.
And
> Every option has pros and cons. Since it's clear beyond a reasonable doubt
> that we can't all agree on purely weak type hints and equally on purely
> strict type hints, it becomes a question of what is the right compromise.
> Adding both - which at least from my point of view has major drawbacks (too
> prominent zval.type exposure; complexity of two systems; internal
> functions issue). Creating something in between that would handle most if
> not all of the use cases the strict camp brought up, while not (IMHO) overly
> focusing on zval.type and making things a lot more noisy/complex for
> built-in functions - is a better direction, whose advantage - I think -
> outweigh its disadvantages.
Again, that changes the type checks from type checks to value checks.
Which is fine for a "weak" mode (default mode of operation), but
really throws away a large part of what many strict proponents
want/need. And they won't be able to be satisfied unless zval.type is
exposed fully. Because that's the point of strict typing and static
analysis (and hence any compromise away from it reduces the value of
the type hint to nothing).
What you call issues, I call strengths. The "internal functions issue"
is not really an issue at all to me because that's the entire point of
type safety. And the fact that internal functions are already built-in
with it is a bonus, not a drawback.
The right compromise is the system that Andrea built. Because it
**wasn't** a compromise (neither side had to give up anything). It
gave both sides exactly what they want and need while letting them
work together transparently. That doesn't sound like a compromise to
me. That sounds like an innovative and ingenious design. And the fact
that it hovered around 2/3 support the entire time shows that. Not to
mention that several people (Daniel and Levi specifically, but others
as well) *only* voted against it because of the declare semantics.
There are a few details that should be worked out:
1. The switch syntax, as Sara straw-polled for (my vote is
declare(strict_types=true) at the top of the file only)
2. The behavior of numeric types.
Now, it's been said before here on this list that "No other language
is this strict about types". And that's patently false. I've done some
research across major typed languages:
VB, C and C++: Allows almost freeform movement between numeric types:
http://en.cppreference.com/w/cpp/language/implicit_cast
Java, D, C# and Pascal follow "widening primitive" style rules:
http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.2
It allows only a widening primitive conversion. That means that you
can call a function wanting a float and pass it an int. But the
opposite is not true (you can't pass a float to a function expecting
an int).
F#, Golang, Haskell, Rust: Types always require explicit conversion
Swift: Types always require explicit conversion (except for between
precisions of a type, int to long for example)
So in fact, only VB, C and C++ implement freeform movement across
numeric types. All the rest limit it in some form.
If we want to add a "numeric" type as a virtual union of int and
float, that's one way to solve the concern. If we don't, we could also
allow widening primitive conversion (int -> float). That wouldn't work
well with bigints, but would be fine in other cases. But there are
plenty of languages that always require explicit type conversion. So
even if we choose that, we're in good company.
I strongly urge you to consider not just the way you'd like to see the
language, but the way others would like to see it as well. It's clear
that there's non-trivial support for strict type-based hinting. Many
people even voted against Andrea's proposal **because it was too
weak**. Please don't ignore this contingent of users and use-cases
because you don't believe in the benefits of the type system.
Thanks
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
