Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75552
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.42 as permitted sender)
Message-ID: <53C563B3.6060905@gmail.com>
Date: Tue, 15 Jul 2014 18:24:03 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <16D48604-0C0A-4613-91A4-21392E3A2636@ajf.me> <CAGAGxbZG+c46P4E2pmEHNnEv=4DyTrHOuXbZu3zAOSU3M6-A-A@mail.gmail.com> <05CE2216-C5D9-4937-9F2E-AA1407284D9F@ajf.me> <53C460DF.5040304@sugarcrm.com> <53C53A96.2040303@gmail.com> <53C55342.1010207@sugarcrm.com>
In-Reply-To: <53C55342.1010207@sugarcrm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: rowan.collins@gmail.com (Rowan Collins)

Stas Malyshev wrote (on 15/07/2014):
> IMO, having consistent rules is much more, orders of magnitude more
> important than serving any particular use case

We are adding a new feature to a language which is already inconsistent. 
We can only make it consistent with one part of the language by making 
it inconsistent with another.

If we take consistency as such a priority that we create a feature that 
is not actually useful, we will have wasted our effort, and made the 
language worse, not better. Saying "who cares if its useful, as long as 
it matches some other part of the language" is a very poor argument IMO.

That's an extreme, and I'm not saying anyone is saying precisely that, 
but I am getting rather weary of the back-and-forth over what is 
"consistent", rather than thinking about what we want to achieve, and 
what is the best way to achieve that.

> What you want is strict typing then.

No, I want to introduce the notion of a "lossless cast", allowing things 
like (int)'123' to be valid. This distinction has been explained many times.

> And if() working the same way -
> after all, if function can be unaware of the flag, if() is definitely
> unaware of it.

Not necessarily. An if() statement is clearly and unambiguously working 
with boolean values. Anyone looking at if( $foo & BIT_FLAG ) can know, 
based on basic knowledge of the language, that an implicit cast is 
taking place.

Someone looking at my_super_function( $foo & BIT_FLAG ) cannot know 
whether that parameter is being interpreted as a boolean or is actually 
being measured against that same BIT_FLAG (or some other integer 
operation) without consulting the source code (or, at least, trusting 
the documentation).

> I am not among them. If you want
> to enforce code style, we already have tools for that, but I don't think
> this particular one should be in the language.

The logical conclusion from that is not to have type hints at all. So 
far, that is in fact the only consensus the PHP community has ever 
reached - not to have scalar type hints. (I don't mean that you 
necessarily hold that position, but it is the logical conclusion of that 
particular line of reasoning.)

Regards,
Rowan Collins
-- 
[IMSoP]