[RFC][Under discussion] Fetch properties in const expressions

Hi everyone

I'd like to start a discussion on a simple RFC to allow fetching
properties in constant expressions.
https://wiki.php.net/rfc/fetch_property_in_const_expressions

The RFC proposes adding support for fetching properties in constant
expressions using the -> operator. I'm looking forward to your
feedback.

Regards,
Ilija
The enum-in-attribute use case came up recently in Symfony. I'm in favor
and the RFC looks good to me.

Genuine question:

In the thread about auto-implementing Stringable for string backed enums,
there is extensive argumentation to explain why ppl that use enums this way
are wrong. You mentioned writing a blog post about these reasons Larry, and
Benjamin (/cc) also expressed a similar opinion.

So my question is: don't these arguments apply here also? Shouldn't we
reject this RFC and tell ppl to use consts instead? If not, why?

Nicolas
A fair question. :-) (Also, I'm working on said blog post literally as we speak.)

I'd say for many of the cases where the inability to use ->value has come up (eg, Attributes), a constant would indeed be the better solution. That's what people should probably be doing there.

However, while there are clear downsides to letting enums auto-coerce to strings (as discussed elsewhere), I don't really see a downside to this RFC. An enum case's value or name properties are guaranteed constant and readonly, so there's no reason I can see to not allow them to be used in a constant, readonly context. That it would allow someone to use SomeEnum::Beep->value in a place where it would probably be better to use SomeConst::Beep instead is a mostly-harmless side effect that doesn't violate any type expectations. And, if anything, the slight clunkiness of the syntax serves as an indicator that maybe you are doing it wrong and should be looking at something else.

So this patch is, in my mind, more about fleshing out a gap that fell through the cracks last version that happens to have a side effect of making connecting enums to pre-enum code possible, if a bit clunky. Auto-converting enums to other types is violating the domain model of different types and confusing their type spaces in semi-magical ways.

(Also, this is an understanding of the problem space I came to just in this past week, and hadn't fully chewed through when this RFC was first put forward.)

Last week I run into this limitation - just sharing in case you would
see it a legitimate use case - not to say it can be done in another way:

I have defined classes for some public identifiers like UserId.
These identifiers should be prefixed which I have defined as constant.

Now as I have a lot of such classes and I want to make sure all of the
prefixes are unique so I added an enum with all prefixes and use the
enum value as constant value as well.

enum IdPrefix:string
{
case USER_ID = 'u-';
// ...
}

class UserId extends AbstractPrefixedUid
{
public const PREFIX = IdPrefix::USER_ID->value;
}

Greetings,

Marc

So, how does this change our mental models when writing PHP? For
example, I generally consider const to be a "compile-time" constant
(ie, generated/created before any code is actually executed). So would
this allow code to actually execute before any other code (ie, by
putting code in a __get()) and thus cause issues due to database
drivers and etc to not be loaded yet -- or cause them to be loaded
prematurely?

True but that's already the case since PHP 8.1 and
https://wiki.php.net/rfc/new_in_initializers
(https://github.com/php/php-src/pull/7153), e.g.
https://3v4l.org/MSWi0:

class Foo {
    public function __construct() {
        echo "Side effect!\n";
    }
}

const C = new Foo();

but as https://externals.io/message/113347#113607 says,
"side-effecting constructors are a terrible idea", and same can be
said for "side-effecting [magic] getters"...

Also note that this only concerns global (or namespace-scoped)
constants (which can also be defined "dynamically" with define()),
not class constants.

--
Guilliam Xavier

Hello, Ilija, Alex,

Yes, that would work fine.

Thanks for the answer!

I am not opposed to this behavior, but it might be better to mention
it in the RFC.

Unlike Enums, an object in a constant can have mutable state, so the
result depends on when the constant expression is executed.

If it is difficult or doesn't have the benefit to determine the timing, it would
be better to clearly state that the timing of the execution of such constant
expression is undefined for now.

It is also an understandable behavior to prohibit the use of normal
objects in the property fetching in constant expressions because of the
difference in mutability between Enum and other objects.

That would mean it would not be supported for

• class constant initializers
• instance property initializers
• static property initializers

The new in initializers RFC doesn't explicitly mention the fact that
it allows class constants having objects via global constant, but
it's already doable in PHP 8.1.

class A {public int $i = 42;}
const BARE_CONSTANT = new A;
class B {
const ClassConstant = BARE_CONSTANT;
}

echo B::ClassConstant->i;

Thanks!

--
Shinji Igarashi

Hi Alexandru, hi Shinji

Hey, sorry to bump here on this topic.

My assumption was that the use of -> in initializers would bear the same limitations as using new.
That would mean it would not be supported for

• class constant initializers
• instance property initializers
• static property initializers

For new clarifications are here: https://wiki.php.net/rfc/new_in_initializers#unsupported_positions

My assumption is that -> would only work for:

• static variable initializers
• global constant initializers
• parameter default values
• attribute arguments

The examples shared by Shinji are for class constant initializers in class C and I'm guessing it would not work.
If that's the case, I think we should clarify this in the RFC as well.

Thank you for bringing this to my attention. I have missed the case
where, through constants, side-effects could be triggered in contexts
where they shouldn't.

class A {
public function __get($name) {}
}
const A = new A();

class B {
public $c = A->c;
}

I was under the incorrect impression that because (new A)->b is
disallowed in property initializers __get could never be triggered in
this context either but since the LHS of -> can be a constant
containing another object this is indeed possible. The problem is
described in the new in initializer RFC [1] you linked. There is
currently no appropriate place where evaluation of the expression
could happen without potential side-effects in places where we don't
want them, like unserialize.

Unfortunately, while thinking about this case I also discovered another issue.

class A {
public $b = 'b';
}
const A = new A;

class C {
public $b = A->b;
}

var_dump(new C());
$a = A;
$a->b = 'b2';
var_dump(new C());

Even without __get the property of an object referenced in the LHS of
the -> operator can change. The engine evaluates the default property
values once for the entire class and then copies the result whenever a
new instance of that class gets created. That means further instances
will use the out-dated property default value from when the first
instance was created. Similarly, function default parameters get
cached between calls. We could evaluate the constant expression for
each object instantiation or function call but degrading performance
for an edge case doesn't seem worth it.

Since the primary motivation of this RFC is to allow fetching the name
and value properties of enums I'm inclined to forbid using -> on
anything but enums. That would circumvent the issue since enums can't
contain user-defined properties nor the magic __get method, and
name/value are readonly.

I'll take a few days to think about the options, and will update the
RFC and inform the mailing list about the decision I have made. Let me
know if you have any more thoughts.

Ilija

[1] https://wiki.php.net/rfc/new_in_initializers#unsupported_positions