strict_types will be default at some moment?

I have been asked by a friend if declare(strict_types=1) will be applied
by
default for some version of PHP, like 9.x or will it be always required
by
all scripts forever. Someone can tell me?

If yes, what is the reason for requiring it? Why it can't be the default
behavior (or maybe, the unique behavior).

The question (which I hear often) misunderstands the original intent of
the declaration, as I understand it: the strict_types switch was not
designed as a transition mechanism for old code, it was designed as a
genuine choice between two different options, both equally new.

Before PHP 7.0, there was no ability for a (user-defined) function to
declare that it wanted an int, string, float, or boolean argument. When
it was proposed that these "scalar type hints" be added, there were
different, strongly held, opinions on how that should work, leading to
at least 5 separate RFCs, several thousand mailing list posts, and a lot
of general unhappiness.

The idea behind the strict_types directive was to combine two versions
of the feature into one system, allowing users to switch between them at
will. The proposal made clear that both modes have their advantages and
disadvantages. A few of those were affected by compatibility with older
code - in particular, around the behaviour of built-in functions - but
those were not the main driving factors behind providing two modes.

Perhaps, 5 or 6 years on, things have changed. Certainly, there are a
vocal community of users who see "strict_types=1" as unreservedly
"better" in some fundamental way - but then, there always were, that's
why the debate was so heated. I rather suspect that most of the
arguments put forward for one position or the other then are just as
true now.

I do wonder if people would even be asking the question, if the modes
had been named something like "scalar_types=coerce" and
"scalar_types=error", and somehow arranged such that neither was in
force by default.

[PS: What a beautifully timed e-mail - "11/11/2020 20:20 UTC"!]

Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

--

To unsubscribe, visit: https://www.php.net/unsub.php

As Rowan pointed out strict_types have a complicated history, and to some
extent were a bandage fix, a very good one which might have been too good.

Let me try to explain by looking at how strict_types circumvented some of
the
nonsensical coercive mode behaviour. (Reminding that this is in PHP 5 days)

1. Preventing float to integer conversion, which could lead to a loss of
   data if a fractional part exists
2. Preventing integers, floats, and strings to pass a boolean type
   declaration
3. Preventing booleans to pass an integer, float, or string type
   declaration
4. Preventing internal functions from coercing null to the corresponding
   scalar type
5. Preventing strings which look numeric (i.e. leading-numeric strings) to
   pass integer/float checks

It should be noted that all of these issues exist (in "weak" typing mode)
in PHP 7
and only the last item of the previous list has been "fixed" in PHP 8.0,
with the
"Stricter Numeric Strings" RFC. [1]

The "competing" RFC to strict_type scalar type declarations
"Coercive Types for Function Arguments" [2] made provisions to some of these
cases, namely 1, 3, and 5. However, they were made as deprecation notices,
which until PHP 8.0, were silenced by default.

Case 4 might finally be solved as in PHP 8.0 a lot of work went towards
making
internal functions accept null (or have a reasonable default value) for
optional arguments.
For case 2 one can argue both ways that it makes sense that non boolean
values resolve
to true or false to pass a type declaration.

Now going back to strict_types being too good of a bandage fix is that
none of the
above issues have been addressed during the PHP 7 release cycle which could
have
made coercive typing less surprising (the float to integer being the most
surprising IMHO)
by introducing warnings/deprecation notices and making them TypeErrors in
PHP 8.

As such I think, it would be better to improve coercive typing during this
major release
cycle by making it stricter and more akin to strict_type semantics such
that the
strict_type declare statement might become "obsolete" in PHP 9.

Best regards,

George P. Banyard

[1] https://wiki.php.net/rfc/saner-numeric-strings
[2] https://wiki.php.net/rfc/coercive_sth