Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80627
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <54B86C63.6070802@gmail.com>
References: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me> <CAPwsocGyv7dp8n=_E1QfrXRSbYZXcHZAPk5F=hDLB070i=SCGA@mail.gmail.com> <4E2073DE-0951-498C-97BB-DDAC094F11FA@ajf.me> <9a033dd1f223f854e760924d118ab812@mail.gmail.com> <CAKUjMCU-57cDpG5ZbDGv10dSqx=Ey40D-WbKxKSnC6oSYOfLWw@mail.gmail.com> <2ae0164cb9b9bf1c974d7a3c60af0466@mail.gmail.com> <F3BC55CD-38CD-42B7-AE0B-A6D34E3D3875@ajf.me> <6105ea99002e634373c09685310e26a6@mail.gmail.com> <D39D18B9-A9E5-430E-B00A-E0DE03DAFE8C@ajf.me> <e131f1aaf3ae0491f958171df36211f5@mail.gmail.com> <85F6139E-6332-4645-91B8-C852B07EA62A@ajf.me> <12433808-9D62-48D3-B66E-74572C61BF68@zend.com> <CALW=WEAzvXde8J6iQ9msG34P7Ukhq6qQONEDvzW+duNSTP-FSA@mail.gmail.com> <CAOsHV+tWaDZP-ZzxQs5XZb2rYvuSNnHW1+tcURKjsMJceps8NQ@mail.gmail.com> <54B85C2B.9000901@gmail.com> <CAOsHV+tqOEz5mTZJOqqu_esrRVsQxPQh-eEPYV+6uRv4-NQiyw@mail.gmail.com> <54B86134.1020801@gmail.com> <CAOsHV+ukrb1HQCHKzbMuzYB4q_xVj1U7pqdxXvVJBCzpzRPSCA@mail.gmail.com> <54B86C63.6070802@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Fri, 16 Jan 2015 09:04:40 +0000
To: PHP Internals List <internals@lists.php.net>
Message-ID: <BF5298CF-55CE-4214-AC32-842AF75B2102@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: rowan.collins@gmail.com (Rowan Collins)

On 16 January 2015 01:41:55 GMT, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>> debate. I'm just claiming that `(int) $num` is more explicit, has no
>> BC breaks and should, IMMO, be the preferred choice.
>
>No, it should not be, and I just wrote two mails explaining why exactly
>it should not. Here's the third.
>
>> Sorry, but this is the syntax used by the manual to describe
>functions
>> usage, not the actual implementation. The manual can be updated. The
>
>Of course, we can rewrite the whole manual and the whole language. 

You're muddling two things here: changing the notation in the manual would require absolutely no changes to the language, as long as it used a self-consistent notation to describe the language's behaviour.

> The
>question is - why we should make such huge changes if we already have
>this meaning and it has been there for years and it always meant
>exactly
>that - coercive typing for scalars - and never meant anything else?

Those reasons have been given many times; in summary, to keep the syntax for coercive hints distinct from the syntax for strict hints, rather than the same syntax meaning one for scalars and the other for non-scalars.

>> implementation itself can't be changed after major version release.
>
>The manual is what people read and rely on. But there's a bigger issue
>that you keep ignoring - that the functions having scalar typed
>argument
>*are* coercive *right now*. You describe it as if it's a typo in the
>manual that can be fixed or something that happened by accident and
>nobody intended it. Nothing can be further from the truth - it's how
>weak typing has been always working in PHP.

Now you are talking about the existence of the feature, not the syntax. It's a good argument for including coercive typing if any type hints are added, but internal functions will not need to be changed based on userland syntax.

> You want new feature for
>your use case? Fine, but claiming existing syntax for it and saying "no
>problem we'd just rewrite the whole manual and disregard 20 years of
>PHP
>history" sounds like a bit too much to ask.

There is no existing syntax in the language for scalar type hints of any kind.

As for the manual, IIRC, there's already precedent for altering its conventions to match language features, when "callable" was introduced as a typehint; the manual previously used "callback" to annotate those parameters.

The manual also uses return type on the left, but I don't think anyone's arguing that decides the discussion on that syntax, which will probably actually put return types on the right. 
It's just a convention in the manual which doesn't actually match any existing PHP code, and can be changed with no compatibility issues whatsoever.

Regards,
-- 
Rowan Collins
[IMSoP]