Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105322
MIME-Version: 1.0
References: <CAC5V6gh79y-i1cQ-XhDBiZTq5BNLDbpcHxNX22mXtYKYrCC94g@mail.gmail.com>
 <CAC5V6ggTMXYYaEEg1A72bBH-fbAc9o+3NyfmmJ1WYEERYZPhgw@mail.gmail.com>
In-Reply-To: <CAC5V6ggTMXYYaEEg1A72bBH-fbAc9o+3NyfmmJ1WYEERYZPhgw@mail.gmail.com>
Date: Sun, 21 Apr 2019 11:17:57 -0300
Message-ID: <CAEsg9X25CrxYGca79ef-cyQ5X2OZUvjB_GEMXLSKz--X0w3LxA@mail.gmail.com>
To: Guilliam Xavier <guilliam.xavier@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000735c0205870b05f6"
Subject: Re: [RFC] Nullable Casting
From: david.proweb@gmail.com (David Rodrigues)

--000000000000735c0205870b05f6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Discussion topic:

- Not 100% needed: is the same that says "nullable typehint is not 100%
need because we can just check in time". This argument has no sense, once
that PHP supports nullable casting for parameters typehint, and the
nullable casting is just a way to fit the argument to parameter typehint
that is already possible, but very hacky ($x !=3D=3D null ? (string) $x : n=
ull
vs. (?string) $x).

- What about e.g. nullable_intval()? intval() is a PHP 4 feature that could
be replaced in 99% of cases by (int) cast. So nullable_intval() make no
sense once that probabily it will be never used (except it (?int) will not
be implemented, but if nullable_intval() could be, so is better (?int)
instead).

- Fallible Casting: it should works exactly as current castings, but with
possibility to be null if it is already null. For instance: (int) "string"
currently will be int (0), by this way, so (?int) "string" should be int
(0) too. The nullable casting will ONLY return NULL if the subject is NULL,
exclusively in this case. So it will affects only (int) null that currently
is int (0). So (?int) null will be null. Same for falsy values: (int) '' is
currently int (0), so (?int) '' will be int (0) also.

- Alternative syntax (null|int): very ugly, no? :P Maybe on future it could
be valid for multicasting eg. (string|int|float) $x, but this is subject to
another topic.

- A cast where you can't be sure of what you'll get back: you will have the
same sure that currently you have with (int) $x, with exception that
nullable values are more explicit because "if $x is null, then you will get
null with 100% of sure". For cases like: (int) 'string', (int) '123string'
and (int) 'string123' what you got? (It is already supported by PHP):
Answer: int (0), int (123) and int (0), respectively.



Em dom, 21 de abr de 2019 =C3=A0s 06:19, Guilliam Xavier <
guilliam.xavier@gmail.com> escreveu:

> On Sat, Apr 6, 2019 at 9:52 AM Guilliam Xavier
> <guilliam.xavier@gmail.com> wrote:
> >
> > Hello internals,
> >
> > David and I would like to open the discussion on our joint RFC:
> >
> > https://wiki.php.net/rfc/nullable-casting
> >
> > Mainly, it would enable to use e.g. `(?int)$x` besides `(int)$x`.
> >
> > We are looking forward to your feedback [...]
> >
> > Thank you,
>
> Hello again internals,
>
> Thanks everyone for your valuable feedback. I have updated the RFC
> with a new Discussion section to [try to] summarize the various
> arguments raised in this thread.
>
> --
> Guilliam Xavier
>


--=20
David Rodrigues

--000000000000735c0205870b05f6--