Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108065
Return-Path: <nikita.ppv@gmail.com>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 84057 invoked from network); 9 Jan 2020 17:09:41 -0000
Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5)
  by pb1.pair.com with SMTP; 9 Jan 2020 17:09:41 -0000
Received: from php-smtp4.php.net (localhost [127.0.0.1])
	by php-smtp4.php.net (Postfix) with ESMTP id 2171A1804F2
	for <internals@lists.php.net>; Thu,  9 Jan 2020 07:15:22 -0800 (PST)
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS 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: <nikita.ppv@gmail.com>
Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172])
	(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 <internals@lists.php.net>; Thu,  9 Jan 2020 07:15:21 -0800 (PST)
Received: by mail-lj1-f172.google.com with SMTP id z22so7667574ljg.1
        for <internals@lists.php.net>; Thu, 09 Jan 2020 07:15:21 -0800 (PST)
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=/VIWs+j50Bo2eiOJbuzAfkx0oAioooLRcdi39vWjoEw=;
        b=mJpcE+kOW73aGGlp4WAN1mr9/T2LkPkZvicz2EA3xiGj0X0trfw78rmAYMXs123Fzw
         2V3Rocp2PLjrXl6QCB0LCNWZNHzl8K0d4Ukdmx65r9LsgXHcKlrOdT1nFC00bAUomIgA
         uxdhHwpzg69R16fpKs/MrWcOiT/VUPFwDznvkXCvIOeGduFSG/0EDivUtFIjBDQqVEL4
         xeJ+CgwlWSQRlivSb7FgMXyMwvT12+cSpjbDgf5dacLwluJlyRhrkiSnT/gcT34h6ymo
         ipmp03j+UmmTMvQZVhO+XAEYnLFOaAIBVXzMYeaHLDwWm/vG84XKGG389l3tgTj/ChO+
         oWQA==
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=/VIWs+j50Bo2eiOJbuzAfkx0oAioooLRcdi39vWjoEw=;
        b=AhXJLpgBB6RfDKi/HucJ7t6jHYRfPZ3S7CVVBlqDfg52BmyDzKO4GHpAffmxwfAW8X
         j+QxSKuJgu7fQTpjX/CPjBxkf+YdK1QrO1kJ69vCR2Py2E0+KI+eCxk5rRdv7ccxjA+8
         47/xakx7IOlxcurxfH8/6zT9NFdK1KNBmA3f1rR580vJSxwJyZ5bxSRsHI+zrJ8qJ8SE
         RkHwKKa7tDSwo9PEreNWTZRipiohEx7ntdEwD48pcLUsQMWmcJwVblesGjwfK2MXjrVf
         0+2PUV87LiJQiwMFpk1N0viGCL9c8hbW+/nObYdnwljSDv2CTaxQfKitXaeN4tyg3ngc
         fotQ==
X-Gm-Message-State: APjAAAXOk2afD8dL1LGLBxG5XZ2Twr1bKToxWZpXobFcOgDIikpc/0vK
	O7oPuyn7GZy/c8M+fHEy54/dSQYEW6+wBNoiH4zQ9aboNSs=
X-Google-Smtp-Source: APXvYqw+k376ZSl7bFFP5Ax0+5WfJUaQBE5Y+CHDxH18Be/slOHe4/E6KcPXQk/5DJi2nej968tgSqVj3UK9x51EaRY=
X-Received: by 2002:a2e:7818:: with SMTP id t24mr7022435ljc.195.1578582919544;
 Thu, 09 Jan 2020 07:15:19 -0800 (PST)
MIME-Version: 1.0
Date: Thu, 9 Jan 2020 16:15:03 +0100
Message-ID: <CAF+90c_RG4Gb-ZXLMoC9bUQ_gb3j37df_s0DqoNKEkohQLDYUg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002b1659059bb67a21"
Subject: Properly validate abstract methods in traits
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000002b1659059bb67a21
Content-Type: text/plain; charset="UTF-8"

Hi internals,

I've prepared https://github.com/php/php-src/pull/5068 to fix validation of
abstract methods inside traits for PHP 8.

To provide some context, the situation is currently pretty weird... when
you add an abstract method in a trait, you obviously do that because the
trait requires that method to exist with the given signature. However, this
is currently enforced only spottily:

 * It is not enforced in the most common case, where the method
implementation is provided by the using class: https://3v4l.org/SeVK3
 * It is enforced if the implementation comes from a parent class:
https://3v4l.org/4VCIp
 * It is enforced if the implementation comes from a child class:
https://3v4l.org/q7Bq2

I believe that an abstract methods signature coming from a trait should
always be enforced.

Conversely, we currently have some very weird code lying around that
instead does a bi-directional signature enforcement if there are two traits
specifying the same abstract method: https://3v4l.org/8Ze2C

I believe this case should be valid instead, as the implementation of the
method provided by the class satisfies both signatures.

Does anyone see an issue with making these validation changes for PHP 8? I
can also make an RFC for this, but it seems more like an implementation bug
to me (especially seeing how there's about zero test coverage for any of
this).

Regards,
Nikita

--0000000000002b1659059bb67a21--