On Mon, Sep 5, 2016 at 11:09 PM, Andrea Faulds <a...@ajf.me> wrote:

> Hi Nikita,
>
> Nikita Popov wrote:
>
>> As I see it, the issue here is really not how to figure out whether a file
>> uses strict_types, the issue is how you mix strict_types=1 and
>> strict_types=0 code in a single file.
>>
>
> This is also my assessment.
>
> Back when this feature was introduced, we decided not to allow this kind of
>> mixing, as it seemed prone to causing a mess and use-cases seemed
>> doubtful.
>> Given the issue Symfony is experiencing, we should reevaluate this
>> decision. Imho it's not good if there are some things you simply *cannot*
>> express in a single file.
>>
>
> I think it was things like this that made me initially allow having
> multiple strict_types declarations in a file. But that was changed later.
>
> Maybe we could allow it, but only with the block syntax, much as we do
> with namespaces? i.e.:
>
> declare (strict_types=1) {
>
> }
>
> declare (strict_types=0) {
>
> }
>
> Or we could allow any number of non-block strict_types declarations if we
> wanted. I don't know.


Next to the question of which syntax specifically we want to allow, this
will also be somewhat challenging to implement, or may require further
semantic restrictions. Currently we only store strict_type information at
the op_array level, which means that we have no way of representing
something like:

declare(strict_types=1) {
    foo($bar);
}
declare(strict_types=0) {
    foo($bar);
}

This means that we either
a) have to represent strict_types at a more granular level, which
effectively means that we have to store this on every call or verify-return
opcode.
b) or we need to restrict this kind of mixed usage further, such that each
block may only contain declarations. I.e. while the above example would be
forbidden, one could still write

declare(strict_types=1) {
    function foo() {}
}
declare(strict_types=0) {
    function bar() {}
}

This would satisfy the given use-case, but it would also introduce a
somewhat arbitrary seeming limitation.

Nikita

Reply via email to