Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83017
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54E3E27B.2010903@lerdorf.com>
References: <CAESVnVoZYiMWQk1Ydc-9wbkJo7Ru_4mrUtrubW=Rh=QKK9o8TA@mail.gmail.com>
	<CAF+90c_S3xT07F-4smHeD=BTuSG9VQZxZ==mhyOzDuBw5QPX_Q@mail.gmail.com>
	<54E3E27B.2010903@lerdorf.com>
Date: Wed, 18 Feb 2015 02:05:49 +0100
Message-ID: <CAF+90c8o8GtO9=7JJ3Jmjzg-=qVAD1aiQaU32joOeD6XH_f4hg@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Sara Golemon <pollita@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b66f6db8dbaef050f526b07
Subject: Re: [PHP-DEV] Scalar Type Hints v0.4
From: nikita.ppv@gmail.com (Nikita Popov)

--047d7b66f6db8dbaef050f526b07
Content-Type: text/plain; charset=UTF-8

On Wed, Feb 18, 2015 at 1:53 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> On 02/17/2015 04:35 PM, Nikita Popov wrote:
> > I don't buy into Rasmus arguments about internal functions. They concern
> > one particular edge case (int->float coercion) and I doubt they have much
> > relevance if applied to codebases with pervasive use of typehints (where
> > you can be reasonably sure of the types of your variables). Even if, for
> > the sake of argument, we acknowledge the concern as valid we should be
> > discussing that particular case (int->float coercion) rather than
> dropping
> > the strict typing for internal functions altogether.
>
> int->float is actually secondary to "123"->int. And while they may be
> edge-cases there are enough of them that we would be pushing people
> towards casting by default which should be a last-resort thing, not the
> first thing you do.
>

The inability to implicitly cast "123" to int is pretty much the KEY
distinction between weak and strict scalar typehints (those pesky
value-dependent type checks). If the strict typing mode doesn't offer this,
what's the point at all?

This is exactly what I fear will happen with an arginfo based approach. If
even fundamental aspects like the "123" vs 123 (or true vs 1) distinction
are suppressed for internal functions, this isn't a strict typing mode,
it's just a weak typing mode with slightly different rules.

Nikita

--047d7b66f6db8dbaef050f526b07--