for me it's weird that to_int() that must return "int" may return not "int".
NULL with ?? seems better than FALSE :)
but if we talk about safety, we should be able to relay on to_int() return
value without additional checks.
Thanks. Dmitry.
On Wed, Oct 22, 2014 at 4:35 PM, Weinand Bob <bobw...@hotmail.com> wrote:
> So, what exactly changes here if we have a second parameter or just return
> null by default?
> It doesn’t make any difference, it’s just another way to write it:
>
> to_int($a, $default)
> or
> to_int($a) ?? $default
>
> Also, if you want exceptions, you always can wrap a userland function
> around it — but I’d rather not wrap an userland function around something
> throwing an exception… inefficient and weird.
>
> Thanks,
> Bob
>
> > Am 22.10.2014 um 12:27 schrieb Dmitry Stogov <dmi...@zend.com>:
> >
> > "null" or "false" return value would make these functions not really
> > useful, because they won't guarantee to return desired type.
> >
> > printf("%d\n", to_int("abcd")); // will print 0
> >
> > The only reliable option to support wrong input is exceptions.
> > On the other hand, exceptions maybe difficult to use or inefficient.
> > We may avoid exceptions throwing, if provide a default value:
> >
> > function to_int(mixed $a , int $default_value = null): int;
> > function to_double(mixed $a , double $default_value = null): double;
> > function to_string(mixed $a, string $default_value = null): string;
> >
> > Thanks. Dmitry.
> >
> > On Wed, Oct 22, 2014 at 12:37 PM, Bob Weinand <bobw...@hotmail.com>
> wrote:
> >
> >> I know we have that already discussed a lot now, but I’d like to expose
> my
> >> points on the return value here:
> >>
> >> I imagine code like (supposing that we ever will have scalar typehints):
> >>
> >> function acceptsInt (int $i = null) {
> >> if ($i === null) {
> >> $i = 2 /* default value */;
> >> }
> >> /* do something with $i */
> >> }
> >>
> >> When we return false:
> >> acceptInt(($tmp = to_int($_GET["userinput"])) === false ? null : $tmp);
> >>
> >> When we throw an exception:
> >> try {
> >> acceptInt(to_int($_GET["userinput"]));
> >> } catch (CastingException $e) {
> >> acceptInt(null);
> >> }
> >>
> >> When we just return null:
> >> acceptInt(to_int($_GET["userinput"]));
> >>
> >> Also, when we want to pass a default value defined outside of the
> >> function, it’s a lot easier now with the coalesce operator:
> >> acceptInt(to_int($_GET["userinput“]) ?? 2 /* default value */);
> >>
> >>
> >> Also, independently of possible scalar typehints:
> >>
> >> Generally exceptions are also a bad idea as the casts probably will be
> >> used on external input and exceptions are **not** a way to handle
> malformed
> >> user input. Really not.
> >> Furthermore, false is a bad idea in the same sense (if we get scalar
> type
> >> hints once), because people then might just catch the EngineException…
> >>
> >> Also, null means "no value"; that’s exactly what we need. If the
> >> to_{type}() functions cannot return a meaningful value, just return "no
> >> value", that means null. And not false, which is a real value.
> >>
> >> That’s why I strongly feel that null is the only true thing to return
> here.
> >>
> >> Thanks,
> >> Bob
> >>
> >>> Am 21.10.2014 um 00:57 schrieb Andrea Faulds <a...@ajf.me>:
> >>>
> >>> Good evening,
> >>>
> >>> I am presenting a new RFC to add a set of three functions to do
> >> validated casts for scalar types:
> >>>
> >>> https://wiki.php.net/rfc/safe_cast
> >>>
> >>> Please read it.
> >>>
> >>> Thanks!
> >>> --
> >>> Andrea Faulds
> >>> http://ajf.me/
>
