Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82851
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.177 as permitted sender)
MIME-Version: 1.0
Sender: rdlowrey@gmail.com
Date: Mon, 16 Feb 2015 10:12:40 -0500
Message-ID: <CAH8Mpn=qXEtZsWVhGw3QPReFxQZgWmUkUcLQQDXw9Hc2JB65eg@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113ed0d4707088050f36049f
Subject: Re: I quit.
From: rdlowrey@php.net (Daniel Lowrey)

--001a113ed0d4707088050f36049f
Content-Type: text/plain; charset=UTF-8

> The 0.1 RFC version was mentioned a lot as a good compromise by many
> people and had major support.

People keep saying this like it's a thing, but I and others are vehemently
opposed to this as a solution. The only thing weak hints accomplishes is
the illusion of safety without actually providing it. You can already
perform lossy casts on your inputs. Weak hints, IMHO, is the worst
available option and I know plenty of folks who agree with me.

Any proposal to the scalar hints problem that doesn't definitively error
out in the `(int) "apple"` case is a non-starter for me; I believe such
solutions are disingenuous at best and dangerous at worst.

I wish people would stop suggesting that there was universal support for
weak hints. There wasn't, and I suspect this dialogue was only avoided
because the proposal gave a good option to those in favor of strict hints.

--001a113ed0d4707088050f36049f--