Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129741 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 492221A00BC for ; Thu, 8 Jan 2026 19:15:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1767899706; bh=+zFci4bQ87pDVHh75+wp1ALOFUqlbkfDnIpOVxYNE7A=; h=Date:Subject:To:References:From:In-Reply-To:From; b=K9jtAxB2W6xgVMy/GpS7gfUHsKoFvOtIoCCefA3Icvt8f2WcrAiCV8y14MyZzF4lB ilFrswqyc4ROspZzZ6h/RvGxkx2PwwYrXA73GjW4UGgwZiC70EfFNUGM5+aPgiFMCQ WCrqvzCvnGmiyn33/BrHUigEAL/8cuLn3ecT3qSBM4HW+NNgJ4Gf6Zg3FwbLcbCP3A c3pZu0tpgQDANUF+nV495SH8qNErGjow7JxAQQhAsmO4OWYDxot1H/qQQm2tfAHqdX 1Jg9U5CNR+nNS1r09IVsvutZEJQvYAwsKlInrKQ4sr4kMwccJZfjA5X/jVO9zaL3F2 G38kVcR0lEYug== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B7D85180068 for ; Thu, 8 Jan 2026 19:15:05 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from fhigh-a3-smtp.messagingengine.com (fhigh-a3-smtp.messagingengine.com [103.168.172.154]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 8 Jan 2026 19:14:55 +0000 (UTC) Received: from phl-compute-11.internal (phl-compute-11.internal [10.202.2.51]) by mailfhigh.phl.internal (Postfix) with ESMTP id D86CD1400046 for ; Thu, 8 Jan 2026 14:14:49 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-11.internal (MEProxy); Thu, 08 Jan 2026 14:14:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rwec.co.uk; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1767899689; x=1767986089; bh=MncVs8h2CG mxGZkg+/HFeih6Vdhz2H02BI9hWkyuyIM=; b=atJY81It7p4+iZOWGTvVYcHo7G CL7xgpazqwq1rGprgqNBi8LXnOlgRHHsiAqwDoKzFokyQJVirjlaS50caIFiSlZQ SXMgitjKVzAArFh0lUjwyp1uBhBQFErn+VnU98/I0CLU0XWVnWgJTCm9gOIkWNBG gaSfgAYVFi/2P+fW9yhGV8FhT7k+owqtrjZ1SDoEIwOyDvV6qsZv6mdMMdU/gxLJ 5E0x1b+KNfC9y7Pr4ejFKaHcItPMZff1CXpgwuyx9gyVKzj9OoDF/eMLYMrHsunq cjhpslQVHgxbZokivSJIYm8y9Eb4hnrqdWxV/bED0OtWkC7uYPxMijDT+yow== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1767899689; x=1767986089; bh=MncVs8h2CGmxGZkg+/HFeih6Vdhz2H02BI9 hWkyuyIM=; b=EJaTNFOtIsSSwOion1/TJ9w8SB8rwTvrNEdziBotCSMUnvjp8dk n0qb0CsEHTiSpXZUcwhIn9S1izxkJ8XSRZ+XkTViHwTxgQZ9MtL8jq2yfMa8RwcZ Avvz6o6/LsqjYStACup5UzfHfaUDHGphpa0a/rc10HhasheODlLIBIyhPfxexq3z lG1frSHUFPB8/ZUKk5wqC8DIdBeRM2Gl86jBfQAaTu5VhUTvKQqHsYOHdpFtr1Cg 7WkMVugwCl7VzKyUyTUWbIS10nNw/GxTTFt7xY4D0EIiz+R+GoVhWX5/dP6KNqr2 rM6qyFG/skevUl6/OzRTP43xmG6TnBqaeHw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddutdeijeeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpegtkfffgggfuffvfhfhjgesrgdtreertd dvjeenucfhrhhomhepfdftohifrghnucfvohhmmhhinhhsucglkffoufhorfgnfdcuoehi mhhsohhprdhphhhpsehrfigvtgdrtghordhukheqnecuggftrfgrthhtvghrnhepkeevhf efheeuheelfeevieeufeetvefgffelgfeuueeukeekkeekhedtfffhgedvnecuffhomhgr ihhnpehphhhprdhnvghtpdhsthgrtghkohhvvghrfhhlohifrdgtohhmpdhmohiiihhllh grrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepihhmshhophdrphhhphesrhifvggtrdgtohdruhhkpdhnsggprhgtphhtthhopedupd hmohguvgepshhmthhpohhuthdprhgtphhtthhopehinhhtvghrnhgrlhhssehlihhsthhs rdhphhhprdhnvght X-ME-Proxy: Feedback-ID: id5114917:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Thu, 8 Jan 2026 14:14:49 -0500 (EST) Content-Type: multipart/alternative; boundary="------------c0hm6fHW1cP52N5Lg2QCju1S" Message-ID: <5b627047-e23d-4dae-9d58-c4fbab41217f@rwec.co.uk> Date: Thu, 8 Jan 2026 19:14:48 +0000 Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PHP-DEV] [RFC] use-from syntax for namespace use declarations To: internals@lists.php.net References: Content-Language: en-GB In-Reply-To: From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]") This is a multi-part message in MIME format. --------------c0hm6fHW1cP52N5Lg2QCju1S Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 06/01/2026 02:14, Stuardo -StR- Rodríguez wrote: > Hello internals, > > I am writing to open the discussion for the RFC "use-from syntax for > namespace use declarations": > https://wiki.php.net/rfc/use-from Hi, and welcome! As you say in the RFC, a new syntax like this "requires a clear and strong justification". Looking at the reasons given, I'm not convinced they pass that test. Let's look at them in order: RATIONALE 1: "makes it easier to scan and (optionally) sort import lists by imported symbol" At first glance, this seems like a reasonable idea, but there are two aspects of PHP's existing syntax which work against it. The first problem is the braced-list form for aliasing multiple symbols from one namespace. Taking the example from your RFC, grouping gives this: ``` use Carbon from Illuminate\Support; use Inertia from Inertia; use {SettingService,TaskService} from App\Services; use {Status,Task,User} from App\Models; use {TaskCreated,TaskUpdated} from App\Events; use TaskRepository from App\Repositories; use TaskUpdateData from App\DTOs; use ZipArchive; ``` This is much more concise, but sorting no longer helps find a symbol (e.g. you have to read each entry to find "User"). Sorting by the first item in a group, as shown, is also unstable: importing "App\Models\Agent" would require moving the fourth line to the top of the list. The second problem is custom aliases, which you propose not one but two new styles for, neither of which allow you to sort or scan by the symbol as used in the file. The first variant actively harms scanning, putting the symbol we're looking for in the *middle* of the statement: use TaskRepository as Repository from App\Repositories; The second variant splits the real name and the alias to opposite ends of the line. The reader has to check both to see which symbol is actually being defined: use TaskRepository from App\Repositoriesas Repository; The existing syntax places the symbol being defined consistently at the end, next to the real name it is aliasing: use App\Repositories\TaskRepositoryas Repository; RATIONALE 2(a): "reducing cognitive friction for developers who regularly move between languages that already use a similar form" This seems to fall down almost immediately, because you quote Python as an example, but it's not in the proposed order! In fact, JavaScript seems to be a rare outlier in placing the imported symbol first: JavaScript: import { Widget } from "acme-lib"; Python: from acmeLib import Widget Java: import AcmeLib.Widget; C#: using AcmeLib.Widget; Swift: import class AcmeLib.Widget Kotlin: import AcmeLib.Widget Scala: import AcmeLib.Widget PHP: use AcmeLib\Widget; RATIONALE 2(b): "makes the import semantics immediately recognizable to a wider audience" As Ben Ramsey pointed out, the opposite is true: the semantics of "use" are *not* the same as JavaScript's "import", so making them look similar sets up false expectations. PHP's "use" statement does not load any code, and doesn't even need to refer to a real class; it is purely a compile-time rewrite rule, more similar to C's #define pre-processor macro. Worse, JavaScript actually has two *different* import syntaxes which resemble the proposal: import { Widget } from "acme-lib" import Widget from "acme-lib" The first is the one which superficially resembles a PHP "use" statement, while the second is actually a short-hand for this, which has no equivalent in PHP at all: import { default as Widget } from "acme-lib" RATIONALE 3: "projects that prefer namespace-first ordering can continue to do so" Superficially, this is true; but having more than one way to write something has a non-zero cost. First, every tool processing the language's syntax has to support the new syntax, even if only to enforce a coding standard that it should not be used. Second, users will not immediately know that the different syntaxes mean the same thing. For instance, users frequently ask the difference between "exit" and "die": https://stackoverflow.com/questions/1795025/what-are-the-differences-in-die-and-exit-in-php This is even more likely given the previous two points: the new syntax will look like JS, where the various different "import" syntaxes *do* mean different things. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import All things considered, if this is ever taken to a vote, I will vote No. -- Rowan Tommins [IMSoP] --------------c0hm6fHW1cP52N5Lg2QCju1S Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 06/01/2026 02:14, Stuardo -StR- Rodríguez wrote:
Hello internals,

I am writing to open the discussion for the RFC "use-from syntax for namespace use declarations":
https://wiki.php.net/rfc/use-from


Hi, and welcome!


As you say in the RFC, a new syntax like this "requires a clear and strong justification". Looking at the reasons given, I'm not convinced they pass that test. Let's look at them in order:



RATIONALE 1: "makes it easier to scan and (optionally) sort import lists by imported symbol"

At first glance, this seems like a reasonable idea, but there are two aspects of PHP's existing syntax which work against it.
The first problem is the braced-list form for aliasing multiple symbols from one namespace. Taking the example from your RFC, grouping gives this:

```
use Carbon from Illuminate\Support;
use Inertia from Inertia;
use {SettingService,TaskService} from App\Services;
use {Status,Task,User} from App\Models; 
use {TaskCreated,TaskUpdated} from App\Events; 
use TaskRepository from App\Repositories; 
use TaskUpdateData from App\DTOs; 
use ZipArchive;
```

This is much more concise, but sorting no longer helps find a symbol (e.g. you have to read each entry to find "User"). Sorting by the first item in a group, as shown, is also unstable: importing "App\Models\Agent" would require moving the fourth line to the top of the list.

The second problem is custom aliases, which you propose not one but two new styles for, neither of which allow you to sort or scan by the symbol as used in the file.

The first variant actively harms scanning, putting the symbol we're looking for in the *middle* of the statement:

use TaskRepository as Repository from App\Repositories;

The second variant splits the real name and the alias to opposite ends of the line. The reader has to check both to see which symbol is actually being defined:

use TaskRepository from App\Repositories as Repository;

The existing syntax places the symbol being defined consistently at the end, next to the real name it is aliasing:

use App\Repositories\TaskRepository as Repository;



RATIONALE 2(a): "reducing cognitive friction for developers who regularly move between languages that already use a similar form"

This seems to fall down almost immediately, because you quote Python as an example, but it's not in the proposed order! In fact, JavaScript seems to be a rare outlier in placing the imported symbol first:

JavaScript: import { Widget } from "acme-lib";
Python: from acmeLib import Widget
Java: import AcmeLib.Widget;
C#: using AcmeLib.Widget;
Swift: import class AcmeLib.Widget
Kotlin: import AcmeLib.Widget
Scala: import AcmeLib.Widget
PHP: use AcmeLib\Widget;



RATIONALE 2(b): "makes the import semantics immediately recognizable to a wider audience"

As Ben Ramsey pointed out, the opposite is true: the semantics of "use" are *not* the same as JavaScript's "import", so making them look similar sets up false expectations. PHP's "use" statement does not load any code, and doesn't even need to refer to a real class; it is purely a compile-time rewrite rule, more similar to C's #define pre-processor macro.

Worse, JavaScript actually has two *different* import syntaxes which resemble the proposal: 

import { Widget } from "acme-lib"
import Widget from "acme-lib"

The first is the one which superficially resembles a PHP "use" statement, while the second is actually a short-hand for this, which has no equivalent in PHP at all:

import { default as Widget } from "acme-lib"



RATIONALE 3: "projects that prefer namespace-first ordering can continue to do so"

Superficially, this is true; but having more than one way to write something has a non-zero cost.

First, every tool processing the language's syntax has to support the new syntax, even if only to enforce a coding standard that it should not be used.

Second, users will not immediately know that the different syntaxes mean the same thing. For instance, users frequently ask the difference between "exit" and "die": https://stackoverflow.com/questions/1795025/what-are-the-differences-in-die-and-exit-in-php

This is even more likely given the previous two points: the new syntax will look like JS, where the various different "import" syntaxes *do* mean different things. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import



All things considered, if this is ever taken to a vote, I will vote No.

-- 
Rowan Tommins
[IMSoP]
--------------c0hm6fHW1cP52N5Lg2QCju1S--