Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82201
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.199 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
In-Reply-To: <54D7EF9D.7040700@gmail.com>
Date: Mon, 9 Feb 2015 00:05:53 +0000
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <5E3D1500-E55D-4FEB-978B-FCA4AE4A1F13@ajf.me>
References: <8703B53E-2C4A-4AC6-95C4-D4F19C6D5221@ajf.me> <CE494877-8C5A-4315-BBF6-089FBD83F148@ajf.me> <54D7EF9D.7040700@gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] Syntactical change to Scalar Type Hints RFC
From: ajf@ajf.me (Andrea Faulds)

Hi,

> On 8 Feb 2015, at 23:22, Rowan Collins <rowan.collins@gmail.com> =
wrote:
>=20
> On 08/02/2015 19:44, Andrea Faulds wrote:
>> Hi,
>>=20
>> I=E2=80=99m posting this in a new thread since people might =
(reasonably) be ignoring further responses to the [VOTE] thread.
>=20
> 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).

Oh yeah, my bad. :/

>=20
>> I=E2=80=99m considering a small change to the Scalar Type Hints RFC, =
specifically about syntax. Quite a few people have said they don=E2=80=99t=
 like the declare() syntax, and it=E2=80=99s easy to see why. It=E2=80=99s=
 rather verbose, it has all the quirks of declare() (such as block =
syntax, not respecting scope), and it=E2=80=99s rather ugly.
>>=20
>> Instead, I=E2=80=99m wondering if the following might be better:
>>=20
>>     <?php strict
>>=20
>> Which would be used like so:
>>=20
>>     <?php strict
>>=20
>>     function foobar(): int {
>>         return 1.0; // error!
>>     }
>>=20
>> It=E2=80=99d be a per-file directive, so there=E2=80=99d be zero =
mixing of modes within one file, and you=E2=80=99d avoid the quirks of =
declare().
>=20
> I find this much, much uglier than declare().
>=20
> 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 "<?=3D =
strict some_function($bar); ?>=E2=80=9D?

<?php strict is allowed

<?php
strict

is not.

It would not be supported for <?=3D. It would be supported for <?. I =
guess it would have to be followed by a new line.

> 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.

It could be renamed to strict_types, but that loses some elegant.

> Would more "strict" features be added to this mode later?

No.

> Or would other keywords be added so that you could, ahem, "declare" =
several directives at the top of your block?

No.

> 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,

I=E2=80=99ve already sent an email in this thread about possible =
approaches to handling multiple blocks. My preferred solution would not =
allow what you describe, and instead behave like namespaces (must be in =
first block, affects entire file).

> 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.

?> isn=E2=80=99t ignored - PHP blocks aren=E2=80=99t, and never have, =
been considered the same as separate files.

> If you make the first "<?php" in a file special, that's still =
something that was never a consideration before.

This is technically correct, but only if that first block is empty. The =
following is an error:

<?php ?>
Test
<?php namespace foo;

Though this isn=E2=80=99t:

<?php ?>
<?php namespace foo;

> 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.

Is there really an important difference between first statement, and =
first opening tag? The main difference in behaviour is empty blocks.

> 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?

Well, it=E2=80=99s not just that which is the problem: declare() is =
rather verbose and ugly. Also, having it behave differently from all =
other declare() statements would bring into question why we even bother =
reusing the declare() syntax.
--
Andrea Faulds
http://ajf.me/