Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105217 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 50168 invoked from network); 10 Apr 2019 20:37:46 -0000 Received: from unknown (HELO mail-it1-f195.google.com) (209.85.166.195) by pb1.pair.com with SMTP; 10 Apr 2019 20:37:46 -0000 Received: by mail-it1-f195.google.com with SMTP id k64so4797189itb.5 for ; Wed, 10 Apr 2019 10:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x4D5JHMj2ny8uDfdHa37v+bU+t6ZIdNFYaAZ9FmZa9Y=; b=qftH3L81WcT2jpkKY1Xoi4hnWoXvf9ZMJ1QL1UwX/S/+Zq5CYa0fL/8tZZl5d27z7v 5n4OhUljeEo+XwAuAVHYdMI8Eic/ddz7yIW1KkjSET3bS2nkU51LHxIbNc+XAUtWRY3Z WN2UsZ5a+3rTgVYHTncc0n4ERbkcHKSPBzuxNosLZdQjCSylJx8aylRv8VAY4dFQfWZe tOCVxKvkYZ42mAP0fJywSHkZ9r3KDzmUDsa5l0t7Y5I9ag5eOaQpcAS+Rzn9TYb6T3e1 xQmWkKm/gvN3JNpKkqoSMR9bGz5e2SzgahRhprqAk7vKwxdDK0axR9F8+x+MXw2HKYb6 XuiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x4D5JHMj2ny8uDfdHa37v+bU+t6ZIdNFYaAZ9FmZa9Y=; b=QLIJ4TE5lArfCYkFNAhmuP9BjKOUQUwQijjPrX84X/IEb0sIEOBQPIrjsjan8Dv7Au GeRdzsgCpIf905sWlR0HmFrMU7g8bMd0agB6mQl76MF8Ft9zxA8TnwfX5FMaQdQKTeNw 1XcH+ZHsyu9iIMEqjONwl41N+B8867lcFhl9iszzwOuG1JncUtik549I9LPegKVydZPL Qaak3QaVSTK0+Cm5i43CGlKwDgRzc0yoZryRGVhr7YmvcfowwJiAzRclCMkiUqMGehe+ av687FG3DtGIIB6boUEJOijpz/EfuspsnYtHMff6MoTd60LrLNhd3SDfdTBdkINhS5d6 Co3A== X-Gm-Message-State: APjAAAX9dC79F3ArYavkFIUVvt421oHZTDb8Cj5n+hFkKjV3sui9pPpJ gkkAwziHcotmrGy41bbO3DoYiIib8vzMnI5MQwo= X-Google-Smtp-Source: APXvYqyQ5JypgHQ47ZXRhuFIPkuJKONltarns2Tv5dDv6TOEqjns/2FnTVKtaiDTExJq8VKh9wSBUHgYXIqZX+mjK+Q= X-Received: by 2002:a02:6011:: with SMTP id i17mr9818265jac.64.1554917696912; Wed, 10 Apr 2019 10:34:56 -0700 (PDT) MIME-Version: 1.0 References: <5cadfed8.1c69fb81.31f7d.1c49SMTPIN_ADDED_MISSING@mx.google.com> <5cae100d.1c69fb81.548c.48a4SMTPIN_ADDED_MISSING@mx.google.com> <5cae1fec.1c69fb81.d2407.c20eSMTPIN_ADDED_MISSING@mx.google.com> In-Reply-To: <5cae1fec.1c69fb81.d2407.c20eSMTPIN_ADDED_MISSING@mx.google.com> Date: Wed, 10 Apr 2019 19:34:44 +0200 Message-ID: To: Mark Randall Cc: PHP Internals Content-Type: multipart/alternative; boundary="000000000000fac42b0586307cfe" Subject: Re: [PHP-DEV] [RFC] Nullable Casting From: benjamin.morel@gmail.com (Benjamin Morel) --000000000000fac42b0586307cfe Content-Type: text/plain; charset="UTF-8" > Function arguments specify what goes *in* to a function, whereas casts > and return types specify what comes *out* of the function. So why would you have different semantics for implicit `(?int)` cast vs `: ?int` function return type cast, if they're both *out*? Return type cast has the same semantics as parameter type cast. > I would still expect the following: > function x(): ?int { return "foo"; } // TypeError because return is > effectively a function > function x(): ?int { return (int?)"foo"; } // null This looks weird to me. I would expect this last line to throw anyway. Having "foo" passed somehow where your code expects an int(ish) or null, should not be silenced and converted to NULL IMO. To me, this last line just says "ignore any error here" - a bit like prefixing it with @. > I don't think it would go down very well to have non-nullable casts > throwing TypeErrors for common cases, without an elegant > could-not-convert fallback that doesn't require a 5 line try-catch block. I can't find a use case on top of my head, where I usually want to silence a failed conversion, other than user input validation; and I don't think type casts are specifically designed for this purpose. Of course there could be helper functions with different semantics, that would perform a cast-or-null-on-failure, such as `to_int("abc") === null`, but having (?int) do this job is IMHO a bad idea which does not help moving the language towards better consistency. - Ben On Wed, 10 Apr 2019 at 18:55, Mark Randall wrote: > On 10/04/2019 17:15, Benjamin Morel wrote: > > No offense, but how can casting semantics different from those already > used > > in implicit casting be intuitive? > > As is implied from the name, an implicit cast is done because the code > needs it to, not because it has been told to by the caller. It is > natural to be more conservative when doing something that has not been > explicitly specified. > > I expect a difference in the behaviour of function arguments vs casts > for the reason that although they share a type syntax, they do have two > very different behaviours. > > Function arguments specify what goes *in* to a function, whereas casts > and return types specify what comes *out* of the function. > > I would still expect the following: > > function x(): ?int { return "foo"; } // TypeError because return is > effectively a function > > function x(): ?int { return (int?)"foo"; } // null > > I don't think it would go down very well to have non-nullable casts > throwing TypeErrors for common cases, without an elegant > could-not-convert fallback that doesn't require a 5 line try-catch block. > > -- > Mark Randall > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --000000000000fac42b0586307cfe--