Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75576
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.207 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <CAEYWF=7YReKc9iKOnFHSWHmYKw1a5y2BU_=Hc5HBbMqdkPTMRg@mail.gmail.com>
Date: Wed, 16 Jul 2014 02:57:11 +0100
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <2DF49CFE-433E-41C9-A48B-1A86338AEE21@ajf.me>
References: <7646A8D1-69A2-4255-B048-D3B9F28B422F@ajf.me> <CAEYWF=4pxA5vE0eBEbi1Fkh7k7uqZk0rAS77oWxzPdicnTN+gQ@mail.gmail.com> <A8E995FC-7F3A-451F-8787-6566CCAE39B5@ajf.me> <CAEYWF=7YReKc9iKOnFHSWHmYKw1a5y2BU_=Hc5HBbMqdkPTMRg@mail.gmail.com>
To: bishop@php.net
Subject: Re: [PHP-DEV] [RFC] intdiv()
From: ajf@ajf.me (Andrea Faulds)


On 16 Jul 2014, at 02:51, Bishop Bettini <bishop@php.net> wrote:

> Hi Andrea,
>=20
> TL;DR -- I agree with the principal but want implemented as the infix
> operator %% with a test for PHP_INT_MIN %% -1 =3D=3D=3D false (and a =
E_WARNING).

%% is perhaps the only good non-keyword syntax choice. I like that.

> As a user, I could implement intdiv and get the same functionality as
> proposed:
>    function intdiv($n, $d) { return (int)($n / $d); }

You could, yes, but it wouldn=92t return the correct result beyond =
53-bit integers, and I=92m not sure it would handle $x/-1 particularly =
well.

>=20
> Heck, I could even simplify further:
>    function intdivmod($n, $d, $m =3D 1) {
>        return (int)($n / $d) % $m;
>    }
>=20
> Though an internal implementation would be faster and would bypass the
> float truncation issue (which IMO is a separate issue and neither a =
pro nor
> con for this RFC),  I feel like we need to confer additional benefit =
if we
> implement this in core.
>=20
> Specifically, I'd want this implemented infix.  Let's call it // for =
now.
> I'd like to be able to:
>=20
> $x =3D 247 // 5;
> $x //=3D 5;
>=20
> The functional notation doesn't afford assign equals.  It collides =
with
> user functions.  It complicates expressions.  (I also don't like pow()
> functionally and wish PHP had an operator like ** for powers.)  So, =
why not
> implement this as an actual operator?

PHP *does* have an operator =93like **=94 for powers=85 the ** operator. =
Did you somehow miss that RFC passing? :)

>=20
> As far as an operator, that's trickier. // and \ would be most like
> existing languages, but those are problematic as already stated.  We =
could
> overload /, relying on the left and right operands to be int to induce
> integer division... but I'm pretty sure that would be more hassle than =
it's
> worth.  So the best I can think of is %%.  That seems ok to me, since =
there
> is some family resemblance between modulus and integer division.

Right. This is just returning the other part of an integer division, the =
actual result itself, not the remainder.

> Finally, I think a test on the other side of the spectrum is needed:
> PHP_INT_MIN %% -1.  Mathematically that should be PHP_INT_MAX+1, I =
believe,
> so a warning and false seems appropriate.

The patch currently returns zero because I don=92t want to yield a float =
like / does, but E_WARNING and FALSE sounds good, we do that for integer =
division anyway.


Do others on internals think that %% is a good syntax choice? Does =
anyone have an objection to it? It wouldn=92t conflict with anything, it =
uses punctuation, and it makes sense.

--
Andrea Faulds
http://ajf.me/