Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82190
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.175 as permitted sender)
Message-ID: <54D7EF9D.7040700@gmail.com>
Date: Sun, 08 Feb 2015 23:22:05 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <8703B53E-2C4A-4AC6-95C4-D4F19C6D5221@ajf.me> <CE494877-8C5A-4315-BBF6-089FBD83F148@ajf.me>
In-Reply-To: <CE494877-8C5A-4315-BBF6-089FBD83F148@ajf.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Syntactical change to Scalar Type Hints RFC
From: rowan.collins@gmail.com (Rowan Collins)

On 08/02/2015 19:44, Andrea Faulds wrote:
> Hi,
>
> I’m posting this in a new thread since people might (reasonably) be ignoring further responses to the [VOTE] thread.

Incidentally, you still used "reply" to create this message, so mail 
readers which base threads on headers (e.g. Thunderbird) rather than 
subject lines (e.g. GMail) still see it as part of the same thread 
(though the subject line change makes it stand out, so I spotted it anyway).

> I’m considering a small change to the Scalar Type Hints RFC, specifically about syntax. Quite a few people have said they don’t like the declare() syntax, and it’s easy to see why. It’s rather verbose, it has all the quirks of declare() (such as block syntax, not respecting scope), and it’s rather ugly.
>
> Instead, I’m wondering if the following might be better:
>
>      <?php strict
>
> Which would be used like so:
>
>      <?php strict
>
>      function foobar(): int {
>          return 1.0; // error!
>      }
>
> It’d be a per-file directive, so there’d be zero mixing of modes within one file, and you’d avoid the quirks of declare().

I find this much, much uglier than declare().

Firstly, it seems to be creating a whole new syntax convention, which 
will need its own rules - Can it be preceded by a newline or other 
whitespace? Must it be followed by a newline (unlike a normal "<?php" 
opening)? Could you enable strict typing in a short tag using "<?= 
strict some_function($bar); ?>"?

Secondly, it is less specific than the current proposal - it suggests 
that PHP has a generic "strict mode", rather than a "strict 
type-checking" mode. Would more "strict" features be added to this mode 
later? Or would other keywords be added so that you could, ahem, 
"declare" several directives at the top of your block?

Thirdly, it has all the same scoping issues as declare() - you can break 
a function up into multiple <?php ... ?> blocks, so it's still possible 
to switch it halfway through a declaration, unless extra rules are 
added. But it's worse than that, because you could start halfway through 
one function, and end halfway through the next:

<?php
function foo() {
// non strict code
?><?php strict
// strict code
}
function bar() {
// still strict
?><?php
// not strict
}

That's impossible with the block version of declare(), because it uses 
the same block syntax of { and } as the rest of the code. It might be 
possible with the non-block declare(), but it would make more sense to 
simply fix that than to introduce a whole new piece of syntax.

If this magic token has the extra effect of causing ?> to be ignored, 
that's a fairly major and unrelated feature, which would probably need 
its own RFC. If you make the first "<?php" in a file special, that's 
still something that was never a consideration before. It's not like 
non-block namespace declarations having to be at the top of the file, 
because that is still a separate statement, it just has to be the 
*first* statement; whereas this appears to be designed to merge with the 
non-statement opening tag.

If you're going to go that far, why not just disallow the block-level 
syntax of declare() for this case, if that is the complaint? Or if the 
problem is the non-block syntax, why not enforce that a non-block 
declare(strict_types) be at the top of the file?

I'm not really sure what problem you're trying to solve, but this to me 
looks like a piece of magic that doesn't resemble anything else in PHP.

Regards,

-- 
Rowan Collins
[IMSoP]