Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83396
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nGOh7FgkbkPGwALmU4SDOs=LvkijAPJeNcG3qrMo7-z-Q@mail.gmail.com>
References: <CAAyV7nGjdguX=4Nt0H=kYnwg8rZ1BkWf8duGZfzheOXXV61pqA@mail.gmail.com>
	<CAAyV7nE+JJPr4iRiFfJg74UVZ_c6HieOmpPQWe6zwnY==m7Zhw@mail.gmail.com>
	<CAAyV7nGOh7FgkbkPGwALmU4SDOs=LvkijAPJeNcG3qrMo7-z-Q@mail.gmail.com>
Date: Sat, 21 Feb 2015 10:35:43 -0500
Message-ID: <CAAyV7nFfzaw=M0En4_3Lt5MYQ7H+ePCzFOuM4wndehxJER7NXQ@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [RFC-Discuss] Scalar Type Declarations v0.5
From: ircmaxell@gmail.com (Anthony Ferrara)

All,

I have updated the RFC to re-target 7.0.

I have also added a new behavior:

Currently, if you install an error handler that returns true, you can
bypass type checking in userland functions.

set_error_handler(function() { return true; });
function foo(int $abc) {
    var_dump($abc);
}
foo("test"); // string(4) "test"

This is obviously a problem for strict typing. Therefore, I am
proposing that strict mode bypass function execution in this case.

The current proposal for engine exceptions would eliminate the need
for this behavior. Therefore I documented the behavior, but am holding
off on the implementation until the engine exceptions vote concludes
(if it fails, the behavior documented in the RFC would be
implemented).

Thanks

Anthony

On Fri, Feb 20, 2015 at 4:09 PM, Anthony Ferrara <ircmaxell@gmail.com> wrote:
> All,
>
>> An interesting point was brought up related to block mode:
>> https://twitter.com/drrotmos/status/568540722586107904
>>
>> Namely that generated file caches may need the ability to switch block
>> mode on-and-off.
>>
>> I'm considering making the change to add that. If that happens,
>> declare must be the outermost block, and no non-declare blocks would
>> be allowed in the outermost scope of the file:
>>
>> <?php
>> declare(strict_types=1) {
>>     //...
>> }
>> declare(strict_types=0) {
>>     //...
>> }
>>
>> Having trailing code or code outside of the declare would be a compile error.
>>
>> <?php
>> declare(strict_types=1) {
>>     //...
>> }
>> foo(); // compile error
>>
>> This behaves consistent with namespace block-mode today (though the
>> strict type declaration would be required to be outside the namespace
>> block).
>>
>> I'm considering adding it, as it's a valid use-case. What do you think?
>
> So, I ran into a snag while doing this.
>
> It turns out that in the parser implementation of declare is not going
> to allow it without significant restructuring (including a lot of
> validation in the compiler):
>
> declare_statement:
> statement { $$ = $1; }
> | ':' inner_statement_list T_ENDDECLARE ';' { $$ = $2; }
> ;
>
> So in block mode, declare supports inline, block and named-block mode:
>
> declare(...) foo();
> declare(...) {
>     foo();
> }
> declare(...):
>     foo();
> enddeclare;
>
> The problem with this is that namespace declarations can only happen
> in top_statement (along with some other statements).
>
> That leaves two options to support multiple modes per file:
>
> 1. Allow in top-level only:
>
> declare(strict_types=1);
> namespace Foo {
> }
> declare(strict_types=0);
> namespace Bar {
> }
>
> 2. inside of the namespace:
> namespace Foo {
>     declare(strict_types=1);
> }
> namespace Bar {
> }
>
> The problem with the first is clarity (it's easy to miss a declare and
> not understand that the mode has changed). We pinned declare to the
> top of the file for clarity. I'm not sure this use-case is worth
> breaking that clarity.
>
> The problem with the second is more subtle. With the current
> parser+compiler, that declare would affect the entire file. It would
> take pretty significant changes and restructuring of the parser to
> effect.
>
> We could drop declare() all together and go with something like a
> namespace modifier:
>
> strict namespace Foo {
> }
> namespace Bar {
> }
>
> But I don't think it's worth it to conflate those two together. Though
> if we did, the syntax "strict namespace;" would be supported for
> non-namespaced strict code.
>
> So in the end, my conclusion is that while it would be nice to support
> the "compiled file" use-case fully, it's not worth it from a technical
> level (the risk and degree of change required doesn't offset the
> benefit of it).
>
> So the proposal will remain unchainged and not support the block
> syntax (or changing the mode mid-file).
>
> Thanks
>
> Anthony