Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118212
Return-Path: <tovilo.ilija@gmail.com>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 34671 invoked from network); 6 Jul 2022 21:17:47 -0000
Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5)
  by pb1.pair.com with SMTP; 6 Jul 2022 21:17:47 -0000
Received: from php-smtp4.php.net (localhost [127.0.0.1])
	by php-smtp4.php.net (Postfix) with ESMTP id 197A9180384
	for <internals@lists.php.net>; Wed,  6 Jul 2022 16:10:55 -0700 (PDT)
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,
	RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,
	T_SCC_BODY_TEXT_LINE 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: <tovilo.ilija@gmail.com>
Received: from mail-il1-f176.google.com (mail-il1-f176.google.com [209.85.166.176])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by php-smtp4.php.net (Postfix) with ESMTPS
	for <internals@lists.php.net>; Wed,  6 Jul 2022 16:10:54 -0700 (PDT)
Received: by mail-il1-f176.google.com with SMTP id h16so2107277ila.2
        for <internals@lists.php.net>; Wed, 06 Jul 2022 16:10:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
        bh=+roY33pAyp3fUbTjD3VJMvwTN1+Uz8jKmXg92pyEaGo=;
        b=JCsyxN0uz25PUCDOqUBAPymervoYUQWKSlddjuKWNktgXvUCqYshxNHYSGNshmPRLd
         xvx4AQyoL0UGHPwSYKp094N0AAfmuJugMRFctvai3OEvzNZHMmve59CSfZYbm3ASGJKh
         Ueibi3y/IIR6R1uTxmQZVjhYgKf7YLylcaOop5oJWdEjHg7N1MQecc/f0eims0DMS15c
         DDDMVVS2Kfbj/428fBWkzd4/cJzb2+lwao3Wi05LtWcZ9sILcDW8KqODlgX/AZ8t9X1v
         qWbU5/UWo2DzbPpW5bhifNFeeYSRv5c9buFDxk6p0Jls7yV/qAQgg+HfqBzNDthyhtIv
         MCOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to;
        bh=+roY33pAyp3fUbTjD3VJMvwTN1+Uz8jKmXg92pyEaGo=;
        b=UJNccp80TiTVk/IcAkZnosAJpZ1CVxpZsmo5S7GsDe9EtcblNo6BoOiqju+BkZHvbl
         EXYjgvCKRCEyCXxt0ys8PvBcYwYuPRtGNRSEgC867iZv25vG/5rlpatjRv5dtbjFFBIK
         kyQsOQ+1ZgabyDhatZxBU8/z5y3K9W5fAz6fgO8JzkFJuuykUQF1MvhSP5LwvAKKc8BL
         0K/1bWcR/awUAkLWPKIxZaAWXyblwAsGiXljrq2B2+5m2fG9W/BD0avEqOnflCZpKo0H
         ATMOaXqQig3yKzFcU3ApP8UBbJ8wapmjseEHbO+wcgVzgVvNdkwMqk+oMwU939roH/1H
         6tIQ==
X-Gm-Message-State: AJIora+ck85a4uWoSOW8KYBotlhNZH54CREqodnGg9M56Bh0YpVYtrAg
	Xb4xGyq9rMXhSs9N2ev/L5cYLgQKsWl/XOuApfHLYeyo
X-Google-Smtp-Source: AGRyM1t7GUQmX5vTTxFDit81542eaIvMzF6u7MQ4gQIQL9mzTTaRVAMm1YzLux3Bz5q6lZJHQyB1smgwEjsogU6tYRM=
X-Received: by 2002:a05:6e02:10d0:b0:2dc:1349:ab99 with SMTP id
 s16-20020a056e0210d000b002dc1349ab99mr11107331ilj.194.1657149053743; Wed, 06
 Jul 2022 16:10:53 -0700 (PDT)
MIME-Version: 1.0
References: <CAPyj-LBYp=CytZfkqaHmKQi9dGnk8p6sBZqb3qe7FjjJ_DbJsg@mail.gmail.com>
 <C18E227B-D72F-46F8-B5EB-5DDE8AF22C2B@beberlei.de>
In-Reply-To: <C18E227B-D72F-46F8-B5EB-5DDE8AF22C2B@beberlei.de>
Date: Thu, 7 Jul 2022 01:10:42 +0200
Message-ID: <CAPyj-LB_V7yBD9mBTdiHWeQ44hjgYgn0reVzVU=g3teXsrsWcQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC][Voting] Fetch properties of enums in const expressions
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Benjamin

> I voted no, because this introduces a special case in const expressions that is hard to explain and seeing it in the wild will give code readers ideas on property access in consts that will never be generalizable.
>
> Imho Const expressions should soley be about declaring state not traversing it.

Thanks for your viewpoint.

We already support quite a few non-trivial operations in constant
expressions. A few examples:

* Array offset fetch
* Coalesce
* Ternary
* && and ||
* `new`

Array offset fetches are essentially the equivalent of `->` on arrays.

```
// This is ok
const C = ['value' => 'b']['value'];
// But this is not?
const C = A::B->value;
```

The two cases semantically seem quite similar. I do agree that it's
unfortunate that `->` isn't allowed on all objects at the moment. But
the issues mentioned in the RFC are solvable, although they require
more caution, time and thought. Since they weren't relevant to the use
case this RFC is trying to solve they were excluded. It's also worth
noting that enums are most likely the primary type of object you'll
find in constant expressions.

Regards,
Ilija