Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105200
MIME-Version: 1.0
References: <40683e93-f8e9-5a8c-9646-31c73c99396f@fischer.name>
 <CAF+90c-cVBy=YaPVz5B2Ua26y_yBz5KRnx9BnjVGe6uHbsi2Bg@mail.gmail.com>
 <5ca53eb4.1c69fb81.e223b.922eSMTPIN_ADDED_MISSING@mx.google.com>
 <CAF+90c8zHTx0f+nb+MBX0=eZus8fi9+fjZq8EYMVfE=xMGTPCg@mail.gmail.com>
 <alpine.DEB.2.21.1904091156040.11325@singlemalt.home.derickrethans.nl>
 <CAF+90c-0RvViQs5xZwhy-4ZGyWZi2Qj-Op742-rG6N6VZKmE2Q@mail.gmail.com>
 <CAG9XoMTQ6otcMzd2VpUCScWWvD_6cg=k+2ao_TWm13iqcAH3bw@mail.gmail.com>
 <CAMuFt-4jTKwV_+n4BPHJRcX5Q0HD=nmzV=FcH1pCM994cdnZTw@mail.gmail.com> <5cadaa32.1c69fb81.95a2d.a393SMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5cadaa32.1c69fb81.95a2d.a393SMTPIN_ADDED_MISSING@mx.google.com>
Date: Wed, 10 Apr 2019 11:37:30 +0200
Message-ID: <CAG9XoMQrwsr4zi5rSbOgwkYFp2U4Og9krnwspmgPScvPOkbRgw@mail.gmail.com>
To: Mark Randall <markyr@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000346deb058629d2bd"
Subject: Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings
From: benjamin.morel@gmail.com (Benjamin Morel)

--000000000000346deb058629d2bd
Content-Type: text/plain; charset="UTF-8"

>
> I'm somewhat split on this one.
> On the one hand, if I make an explicit cast, my intention is clear, make
> the best attempt to convert this string into a number. Trimming
> whitespace would be a natural consequence of that.
> On the other hand, I'm a stickler for consistency.
> On the balance of things, I would most certainly like to see leading and
> trailing whitespace render a string ineligible to be implicitly
> converted, but I'd be satisfied with (int)" 123 " converting without error.
>

I'm all for consistency between `(int)` casting, `(int $x)` function
parameter and `: int` return type, *even* if this justifies allowing
leading and trailing whitespace around numbers, if this helps adoption.
As long as we no longer allow `(int) "abc"` to return `0`, I'm game.

On the topic of errorsfor explicit casts I'd be more inclined to also
> introduce (?int) and in the event the value cannot be converted, return
> null.


If (?int) casting is introduced, I would only return null if the original
value is null. Otherwise, throw an TypeError.
This is the only consistent behaviour with scalar type hints and return
types.

Ben

--000000000000346deb058629d2bd--