Collision of interface constant and trait constant doesn't produce fatal error

[MaXal]

Description

The following code:

<?php

trait MyTrait{
    const A = 1;
}
interface I{
    const A = 2;
}

class D implements I{
    use MyTrait;
}

echo D::A;

Resulted in this output:

1

But I expected this output instead:

Fatal error: I and MyTrait define the same constant (A) in the composition of D. However, the definition differs and is considered incompatible. Class was composed in /in/EVuKh on line 10

PHP Version

8.2

Operating System

No response

[iluuu1994]

@sj-i FYI. Can you take a look? This is an example from the RFC:

trait T1 {
    public const CONSTANT = 42;
}

interface I {
    public const CONSTANT = 43;
}
 
// Fatal Error
class C4 implements I {
    use T1;
}

However, there is no error here.

[Girgias]

I'm pretty sure this is expected behaviour since the change introduced by https://wiki.php.net/rfc/final_class_const where Interface constants are now override-able by default, and the trait overrides the constants.

[iluuu1994]

@Girgias That makes sense. Then the example in the RFC was incorrect (the constants in traits RFC was voted on AFTER the final const RFC).

[sj-i]

There are two possible interpretations here.

One is that class constants inherited from interfaces conflict with trait constants, and the other is that constants introduced into classes from traits can override constants defined in interfaces.

The RFC for trait constants adopts the former, in line with the following behavior for trait properties and class inheritances.
https://3v4l.org/84abA

So this is indeed a bug. I have a fix on my end and will PR it later.

[kocsismate]

I think it shouldn't matter if an interface constant is overridden by a constant defined in an implementing class or in a trait which is used by an implementing class, so I'm fine with the situation we have now (except if final interface constants are overridable).

[sj-i]

I would rather recommend a more restrictive behavior as described in the RFC for now.

In the current implementation, trait constants can conflict with constants inherited from parent classes. If trait constants are allowed to override interface constants, then the behavior with inheritance needs to be changed as well.

And if we do so, it would become inconsistent with the current behavior for properties. In other words, the order of application for inheritance and trait usage would be different between constants and properties.

Unless there is a strong demand, I think it is easier and preferable to make the behavior as described in the RFC via merging #9274

[sj-i]

Note that I would have no problem if trait constants could override constants in parent classes, as long as the behavior reflects further discussions and considerations in internals.

Although this is a comparatively trivial issue, I think it would be better to have a separate RFC for this change, as it should be consistent with the existing behavior for properties.