Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105845 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 40300 invoked from network); 6 Jun 2019 11:43:34 -0000 Received: from unknown (HELO mail-lf1-f45.google.com) (209.85.167.45) by pb1.pair.com with SMTP; 6 Jun 2019 11:43:34 -0000 Received: by mail-lf1-f45.google.com with SMTP id y198so970740lfa.1 for ; Thu, 06 Jun 2019 01:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xUXtoSVvZDUUyljTx4HHSdmJuuk2syOQSd95CkmJ/hE=; b=j66nG9iR9i/hCVx5AJF6QAchGcXKZ0zMx7C3PwgRj4TYhn4beCG8pgOVgwse4J1pz/ ABUP/jKY9B/iyPQ9TnsLPeqolfDSiLgpqbjYFeyZThUTD3yvliPtWZRqkCEtd1ROT4nA Kgp4cxeZJmG3+NXp/kOKK0kt+Fwp8foZA6XwMD8qKmyi3ZiWsan+/7FdXxP52eFEXcR0 DTDYmlh7f9SMOqoRwnBZYxLQXtU3VvVGOM0ZuVJUDbvTzlqbpSammh7n/2JSsyVzIHTK JOARvUWO44zbhbV4k9iUm4lDfHeW3wjPlhpPie5cw/jhWj7bsHHTjEWBza2k3gBLwqoB Cl+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xUXtoSVvZDUUyljTx4HHSdmJuuk2syOQSd95CkmJ/hE=; b=E/fSGWbzzP8Vg+iPcSEfKdBvTXMPbQbcTHLMgyCovFEmEWrRxVMTs2Cnz2BVP+prMV e03Hb/2ntFjLcdLNBZVLVM3g85aqfRJaWClCSAQcSbhQAkaa+DWNpQXtnrDQlP8f7l0J gzxJlafLPeq+vX/fS/An/3gGuLExpZ8mhkvgAt/keXzmV4s4dBA6Ywwl6RrWu1CtvY9H klZEohg8zx8faCtFr/qJtNo4PVaR38yxSxg8fYgF9LQzkw/Ua8iURSvw76K5sILcQ+F1 +YcgLIKNBRpj3nHBtc4HbyCyMuYuOH+hKu7hSjKDTjG/EjQOXC42vixI4uHIh69Z3SCc lS9Q== X-Gm-Message-State: APjAAAV04JKp7BJubA1bSJPn+pGYAUf7kjzQbl9tihtNrUzsLDAuKf8u EyNy3aghMXaWA3KhfhfvhVcIZc5/UobB0jVwvXcEyK5DLXkTqg== X-Google-Smtp-Source: APXvYqzxzEoOliQyDI5rpd4cc2b3nheWlxTv05LVLyyOa+NEoO+obPDC/rj78PFjCfeQpc7ebgrNRdGoAErW9b1ADgY= X-Received: by 2002:ac2:4a78:: with SMTP id q24mr21020837lfp.59.1559811294927; Thu, 06 Jun 2019 01:54:54 -0700 (PDT) MIME-Version: 1.0 Date: Thu, 6 Jun 2019 10:54:38 +0200 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="000000000000269f1b058aa3de28" Subject: Handling of null arguments to internal functions From: nikita.ppv@gmail.com (Nikita Popov) --000000000000269f1b058aa3de28 Content-Type: text/plain; charset="UTF-8" Hi internals, The https://wiki.php.net/rfc/consistent_type_errors RFC resolved one of the big differences in argument handling between internal and userland functions. This change allowed us to add return type information (available through reflection) to internal functions, something that Gabriel Caruso has been working on. During the discussion of that RFC, Andrea raised another important difference: User functions do not accept null for a typed argument, unless it is explicitly nullable (through ?Type or a null default value). This is independent of whether the type is scalar (int and array both reject null) and also independent of strict_types. For internal functions on the other hand, in weak typing mode, null will be accepted to scalar arguments and coerced to the respective type. For example strlen(null) becomes strlen('') becomes 0, without emitting any diagnostics. More precisely, this is a difference between two different argument handling approaches, arginfo (used by userland, forbids null) and zpp (used by internal, allows null). As we would like to also use arginfo for internal functions (as it is available through reflection, while zpp is not), we need to resolve this discrepancy in some way. The "correct" thing to do would be to forbid passing null to non-nullable arguments for internal functions / zpp as well, making behavior fully consistent. I've created https://github.com/php/php-src/pull/4227 to prototype this and see how the test impact looks like. However, I think there will be a lot of fallout from this change. When running this patch against the Symfony test suite, I get many thousands of deprecation warnings (though many with the same root cause). In some cases, it's a matter of us not marking arguments as nullable that likely should be, e.g. I was able to remove a slew of deprecation warnings by making the $pattern argument in NumberFormatter/IntlDateFormatter nullable. This is what I originally wanted to propose here, but after seeing the impact this has (relative to, say, changing == semantics) it might not be a good idea. If we don't want to do that, then we should start accepting null for scalars for internal functions in arginfo as well. It will resolve the arginfo/zpp discrepancy, but will leave the divide between internal/userland functions. Thoughts? Regards, Nikita --000000000000269f1b058aa3de28--