Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109721 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 49664 invoked from network); 20 Apr 2020 17:14:57 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 20 Apr 2020 17:14:57 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1630B1804C7 for ; Mon, 20 Apr 2020 08:46:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 20 Apr 2020 08:46:05 -0700 (PDT) Received: by mail-wm1-f49.google.com with SMTP id 188so49487wmc.2 for ; Mon, 20 Apr 2020 08:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beberlei-de.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jd6y3yLUCO0nXgVj1kIGcQK+/xL0IuH9BZqGNe8pWmA=; b=xNZxzWor+CZWhB3pr6p4e4KDGF+hTaVNjBdbtMzaI7cVckwRuUloVgy6lE1gm+BcOZ GyLRlMDDxzIi6GAB3zaHCPmg9ve3zQEHSblyKYlAoaKpexM/CwUOEdKstVJGuRAPDVye 2NHvpyRzb32Gt03AkuHuxpT9s765FK7upI6whnrHfTp7RTsAmOIPLqIi50Tm3u/5uzVN KcrNclP2p+7qMgPMknlZjt1mJAr0pm7NrA89Z4ALYgQXACod+ScJyT6pksip+zcJrUAQ 5YPtWTlhTck8ay0RCKeq82J1cOmGuro083awuVOg1PW8zjXSrnoYBlnwsFjo8W5KExue SHbA== 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=jd6y3yLUCO0nXgVj1kIGcQK+/xL0IuH9BZqGNe8pWmA=; b=dVudGIwy/Hsc+oAeL6n2hvMEPCq62USfHeAWhOp+U8qLL6U/ZaymQUC9trKr+dGLZv XpEtHWyW2GvzQf3ZKco0zWAI0t7nhfvdQbc78zL/723msVC8kFZJ/t81swVmkRVYTmWN 3B6lZ6p6KmgmVxAq6GST0s2evA2CMRyjj5/Urora4JCOjQV3oG1eyvVM+NWJ2SvwOW/P QSJHyT/xlMlK75gC3U5hU+Tc+4OFsTapE+ZgvchBzK1BwkFYe0QQlAoQWjFW70ZqTs7O 1ki6BKWeI5U6TCE7/LgkwBzLF+zYfHbhbyRxsp6s0UxqhkYRXPnHM7NwmwUYkK2q9Tj/ 4TqA== X-Gm-Message-State: AGi0PuYsi1knJGO1vQyGg8yaQY9eUeilIXB7Kw4lVMaajJIh2GpGzzno W2D1YTr2q5yUA6inehr9bQzaKaPqV/orMdpN3IcQN1A3 X-Google-Smtp-Source: APiQypJMhQX1ywb23d92K7aoFbquLL+ZxIRvmGaxX3WE6YheAG+awMTePPEdkJdrYQPJlsJc1iROjyLMVlaEuviRgBk= X-Received: by 2002:a7b:c0d5:: with SMTP id s21mr18260695wmh.107.1587397559332; Mon, 20 Apr 2020 08:45:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 20 Apr 2020 17:45:48 +0200 Message-ID: To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="000000000000a4473405a3bacbd4" Subject: Re: [PHP-DEV] [RFC] Mixed type From: kontakt@beberlei.de (Benjamin Eberlei) --000000000000a4473405a3bacbd4 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 20, 2020 at 5:17 PM Larry Garfield wrote: > On Mon, Apr 20, 2020, at 9:15 AM, Sara Golemon wrote: > > On Mon, Apr 20, 2020 at 8:52 AM Larry Garfield > > wrote: > > > > > On Mon, Apr 20, 2020, at 6:17 AM, Dan Ackroyd wrote: > > > > Here is an RFC for adding a 'mixed' type to the language: > > > > https://wiki.php.net/rfc/mixed_type_v2 > > > > > > > > > > I am not against this, but now that we have Union types what places are > > > there where the currently available type declarations are insufficient? > > > Resource seems like the only remaining gap where you'd be forced to use > > > `mixed` instead of a union. > > > > > > I imagine some type combinations get pretty wide. Like, this is > verbose AF. > > > > null|bool|int|float|string|array|object|resource > > Sure, but how often is that an actual description of what the code > accepts? I... cannot actually envision what code would actually accept > that mess. :-) > I can think of quite a few: - var_dump, print_r, more generally debugging/logging functions and wrappers thereof - json_encode, serialize, and more generally serialization and encoding functions, as return value as well for the inverse operations - database/nosql related functions (bindParam, bindValue) and as return value from generic functions like fetch() - Xpath::evaluate - ldap query functions And wrappers of these extensions could benefit from passing on the mixed type explicitly. > With union types and stringable already on the way, I'm not sure what > other non-hypothetical use cases would still be that fugly that you'd now > need to fall back to `mixed`. (I still think intersection types are > needed, but that's a separate matter.) There may be, but I cannot think of > them. > > > For the long term good of the language I'd prefer type aliases (or > typedefs > > or usings or whatever you want to call them. > > > > use mixed = null|bool|int|float|string|array|object|resource; > > use scalar = null|bool|int|float|string; > > use number = int|float; > > Concur. > > > That said, baking 'mixed' in as an implicit alias of the above isn't > > problematic for that future. > > > > -Sara > > Concur. > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --000000000000a4473405a3bacbd4--