Fix GH-10497: Allow const obj->prop = value

[khaledalam]

Description

Fixes #10497 - Allows direct modification of object properties stored in constants, for both global constants and class constants.

RFC: https://wiki.php.net/rfc/const_object_property_write

Problem

Previously, this code would fail with a fatal error:

const a = new stdClass;
a->b = 42;  // Fatal error: Cannot use temporary expression in write context

The constant binding is immutable, but the object it holds is mutable by design — so the write should be allowed.

Solution

In zend_delayed_compile_prop(), when the object expression is a constant used in a write context (BP_VAR_W/RW/UNSET/FUNC_ARG), fetch the constant at runtime instead of treating it as a temporary:

• ZEND_AST_CONST → emit ZEND_FETCH_CONSTANT (global constants)
• ZEND_AST_CLASS_CONST → emit ZEND_FETCH_CLASS_CONSTANT (class constants)

Because the constant is fetched at runtime (not compile-time evaluated), the property write targets the real object.
The constant binding itself is never modified.

Scope

Supported:

• CONST->prop = value; // global constant
• Cls::CONST->prop = value; // class constant (via class name)
• $obj::CONST->prop = value; // class constant (via instance)
• …including compound assignment, ++/--, .=, isset()/unset(), by-reference passing, and nested chains.

Still rejected (unchanged):

• Rebinding a constant (CONST = ...) — parse error
• Dimension/array writes on constants (CONST[0] = ..., CONST["x"] = ...) , these write to a temporary, so they remain a compile error

Backward incompatible change

Enum cases are class constants, so they're affected. Writing to or unsetting a readonly case property, e.g. unset(Enum::Case->value) or Enum::Case->value = x , now raises the standard runtime readonly-property Error instead of the previous compile-time "Cannot use temporary expression in write context" fatal. This matches plain variable access ($x = Enum::Case; unset($x->value);). Enum case properties remain immutable.

[iluuu1994]

Thanks @khaledalam! Looks reasonable overall.

[khaledalam]

Thanks @khaledalam! Looks reasonable overall.

Thanks @iluuu1994 for the feedback, all comments addressed.

[iluuu1994]

Cool, thanks @khaledalam! This is a language change and should be discussed on the internals mailing list at least. I think this will impact GH-13800, but that's not a major issue.

[iluuu1994]

Btw, one thing in particular people might object to is:

const arrayTest = [1, 2, 3];
arrayTest[] = 4;
var_dump(arrayTest);

This becomes valid, but prints:

array(3) {
  [0]=>
  int(1)
  [1]=>
  int(2)
  [2]=>
  int(3)
}

I.e. the assignment has no effect, because it happens on a temporary value. Make sure to mention this in your e-mail to internals.

[khaledalam]

I've opened an internals thread and sent an email for discussion: https://news-web.php.net/php.internals/129757

[iluuu1994]

It sounds like @TimWolla objected, so this would need an RFC, or at least the mitigation from https://news-web.php.net/php.internals/129839.

[TimWolla]

Yes, my replies on the list were an objection against the PR as-is. Selecting request changes for visibility.

[khaledalam]

Noted, I'll look into it