Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114923
Return-Path: <come.chilliet@fusiondirectory.org>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 34616 invoked from network); 17 Jun 2021 09:36:29 -0000
Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5)
  by pb1.pair.com with SMTP; 17 Jun 2021 09:36:29 -0000
Received: from php-smtp4.php.net (localhost [127.0.0.1])
	by php-smtp4.php.net (Postfix) with ESMTP id 99AA71804C9
	for <internals@lists.php.net>; Thu, 17 Jun 2021 02:53:27 -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,SPF_HELO_NONE,SPF_PASS
	autolearn=no autolearn_force=no version=3.4.2
X-Spam-Virus: No
X-Envelope-From: <come.chilliet@fusiondirectory.org>
Received: from smtp-in.fusiondirectory.org (smtp-in.opensides.be [195.154.20.156])
	(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, 17 Jun 2021 02:53:27 -0700 (PDT)
Received: from smtp-in.fusiondirectory.org (localhost.localdomain [127.0.0.1])
	by smtp-in.fusiondirectory.org (Proxmox) with ESMTP id 2C509101485
	for <internals@lists.php.net>; Thu, 17 Jun 2021 11:53:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	fusiondirectory.org; h=cc:content-transfer-encoding:content-type
	:content-type:date:from:from:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fusiondirectory;
	 bh=dbARyjeszWMRw719zrkK10YV6pwyF6bo+aPZAqJB/+c=; b=0sHh7coOlc/y
	O/zFP9jUJtyVX06a04v8iq6GfHVUGREklxCMHJE3IULrL0kxMc1fmtEH50D2vTpo
	vzrPL7OiZkjJrnl41MK7owXJVUrWDQG8PdCwEDxTlrQe3i/9co/5EujyazpLfQNq
	tNIA4wt/SR9AKW7J5E1JbjmdnfB2prMUYTa5yOv3ctcadsD3ClbvwzdCBk+i9j0m
	03FVxh+UyAOX/YO78WpFPYKUAUcQhrO+rzLG1SkCym4uKQPrL6phPCZ4XSkP2y8T
	C9QNccGDptGEMzPS1AwYbKJeyTQKFOsK9KVzMvKqkCecrPVf42UKq+0vcuwFO+1O
	uOokNWbplQ==
Received: from smtp.fusiondirectory.org (smtp.geekview.be [195.154.20.141])
	by smtp-in.fusiondirectory.org (Proxmox) with ESMTP id F0CF310076B
	for <internals@lists.php.net>; Thu, 17 Jun 2021 11:53:24 +0200 (CEST)
Received: from mcmic-probook.opensides.be (63.120.199.77.rev.sfr.net [77.199.120.63])
	by smtp.fusiondirectory.org (Postfix) with ESMTPSA id BE9B925CB72
	for <internals@lists.php.net>; Thu, 17 Jun 2021 11:53:24 +0200 (CEST)
Date: Thu, 17 Jun 2021 11:53:23 +0200
To: internals@lists.php.net
Message-ID: <20210617115323.1a6c26d7@mcmic-probook.opensides.be>
In-Reply-To: <CAF+90c_nKeFJMD8zZefCHNEhZyrp9snuKgj8VRxNhwUi8h41Bw@mail.gmail.com>
References: <CAF+90c-HY-0fx+pTmntRJZKcQcZFfk3uJwrZ6FAMAx5_Wj+JHw@mail.gmail.com>
	<88588b8f-5729-4458-90b1-c602f751e128@www.fastmail.com>
	<CAF+90c9EaGreC0y6FagwLn+2OSQUgcQe9UmQdzZaqEYGw0aJbQ@mail.gmail.com>
	<33fd3541-8518-4f98-a258-705f85180ed1@www.fastmail.com>
	<CAF+90c_nKeFJMD8zZefCHNEhZyrp9snuKgj8VRxNhwUi8h41Bw@mail.gmail.com>
Organization: FusionDirectory
X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] New in initializers
From: come.chilliet@fusiondirectory.org (=?UTF-8?B?Q8O0bWU=?= Chilliet)

Le Wed, 16 Jun 2021 10:16:37 +0200,
Nikita Popov <nikita.ppv@gmail.com> a =C3=A9crit :

> 1. Eagerly evaluate initializers on declaration. This is what I tried in =
an
> earlier revision of the RFC, and I don't think that approach works. It
> breaks existing code and has various other unpleasant complications.
> 2. Precisely specify the current behavior. I don't want to do this either,
> because the exact places where evaluation happens are something of an
> implementation detail. If in the future we find it convenient to separate
> evaluation of non-static properties on object instantiation from evaluati=
on
> of static properties and class constants (which are not strictly needed at
> that point), I'd like to retain the liberty to make such a change.
> 3. Do not specify an evaluation order, beyond that evaluation happens at
> certain uses of the class. Evaluation order may change across PHP version=
s.
> If your code relies on any particular order, your code is broken.

If option 3 is considered, it means the evaluation order may change, if we =
can
change the evaluation order, why not go for option 1? I do not understand w=
hich
existing code can break with option 1 and be fine with option 3, it means t=
his
code relies on undefined behaviors, no?

C=C3=B4me