`strict_types` Breaks Consuming Code about laminas-diactoros HOT 2 CLOSED

https://github.com/php-fig/http-message/blob/efd67d1dc14a7ef4fc4e518e7dee91c271d524e4/src/StreamInterface.php#L108-L115

    /**
     * Write data to the stream.
     *
     * @param string $string The string that is to be written.
     * @return int Returns the number of bytes written to the stream.
     * @throws \RuntimeException on failure.
     */
    public function write($string);

As per the method signature false is not a valid value and it never was before.
Introduction of strict types did not change the signature so it is not a BC break for supported usage. In effect, what you experience is a bug on consumer side that was silently swallowed before but now it got exposed.

Aside for some specific cases, we implicitly trust framework users to adhere to interface as introduction of checks for all possible misuses will have negative impact on code readability and performance. There are tools that can be used as part of QA to detect those problems. Psalm and phpstan are probably the most used open source tools.

Generally, while I understand where you come from with a sloppy PHP type juggling usage custom in the community, depending on undefined and unsupported behavior have severe impact on code reliability and maintainability as highlighted here. I would recommend to proactively detect and fix it.

Since I do not consider this a bug on our side, I will mark the issue as invalid.

from laminas-diactoros.

@Xerkus not sure I'd call it a consumer side bug, as before enabling strict types, type juggling could be reasonably expected (and to some extent, is still ambiguous, because the type is no more than annotation, not a proper hint).

But I don't disagree with closing this at all. Thanks for the quick reply.

from laminas-diactoros.