On Tue, Jun 18, 2024 at 11:04 PM David Gebler <davidgeb...@gmail.com> wrote: > > On Tue, 18 Jun 2024, 17:40 Robert Landers, <landers.rob...@gmail.com> wrote: >> >> Hello internals, >> >> Many, many people start their files fairly religiously: >> >> <?php declare(strict_types=1); >> >> and I say "religiously" because from talking to people in real life, >> reddit, workplaces, etc, very few php programmers actually know what >> this does but do it nonetheless. > > > I think there's almost certainly a degree of truth, not just in PHP but > programming in general, in the idea that there are many people who will > blindly follow a convention for no better reason they once heard someone they > considered more senior than themselves say the words "best practice" > > But I don't think the meaning of strict_types in PHP is unclear. It's right > there in the manual > https://www.php.net/manual/en/language.types.declarations.php#language.types.declarations.strict > > If anyone is daft enough to use a language feature without referencing what > it means or what it does, let them clean up any problems which arise for them > as a result.
The problem isn't so much this, but in that it has become a dogma to "have working types" and trying to explain why they do or do not need/want it in the current context becomes a hopeless argument because you are attacking their world-view instead of having an academic argument. > > If I were to support any change to how this feature works for PHP 9, I think > it would be providing a mechanism to enable it for all files at once, maybe > either via a .ini setting such as strict_types_default=1 or a new declare > which applies to all files included or autoloaded from that point on, i.e. a > declare that could be used as the first line of an entrypoint script to make > all files in a project have strict typing mode enabled/disabled (unless a > particular file overrides for its own scope with its own declare). I've explicitly written code without strict types because, in that context, I want coercion (mostly when dealing with env vars) surrounded by files with strict types enabled. Multiple steps would have to be taken to make this possible (i.e., requiring the setting on every file, whether off or on), negating the entire feature of having it set globally. There may be a path where this makes sense, but I don't think we can get there from here. > > Changing the name to anything other than what it is now, with or without > flipping the value, just seems like a major BC headache for no gain. > > -Dave Robert Landers Software Engineer Utrecht NL