Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125538
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 13 Sep 2024 13:46:39 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <49f0d3f3-7977-4fee-94d3-cdc6b9e55526@app.fastmail.com>
In-Reply-To: <212fd466-85bc-4447-90b7-8fe5426d1bd1@rwec.co.uk>
References: <0fa39535-f22d-4eba-b4df-90abe39e683a@app.fastmail.com>
 <e73be2b0-faa9-42eb-a9f6-8308cf4f8c94@app.fastmail.com>
 <ed3847bf-af2e-4e33-ac09-66e44696fdeb@app.fastmail.com>
 <79e58673-50ec-461e-a998-736b020e4287@app.fastmail.com>
 <a3cd6d90-cfac-40d5-a59a-c9f6d9dbe5f0@app.fastmail.com>
 <928A2984-6035-4DA6-9EA7-12E85237C270@php.net>
 <0d461700-1b6c-44fd-9cda-aa698de49847@app.fastmail.com>
 <667233C2-BC47-4530-8142-D90E6907FE63@daveyshafik.com>
 <D95D21CE-45AB-487A-B59D-40305C0C569D@rwec.co.uk>
 <63d241a8-a34a-498c-a5f9-f34230aa5afa@app.fastmail.com>
 <4C7A7F27-B787-44CA-B664-CEF4B9B412FB@newclarity.net>
 <212fd466-85bc-4447-90b7-8fe5426d1bd1@rwec.co.uk>
Subject: Re: [PHP-DEV] bikeshed: Typed Aliases
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Sep 9, 2024, at 4:35 PM, Rowan Tommins [IMSoP] wrote:
> On 09/09/2024 19:41, Mike Schinkel wrote:
>
>> Referencing prior art (e.g. Go) PHP could allow int literals =E2=80=94=
 e.g. `1`, `47`, etc. =E2=80=94 to be passed to typedefs derived from in=
ts but require int variables to be typecast to the required type. Same f=
or string literals.=20
>
> That's an interesting compromise, worth considering.

I have concerns about this.  Mainly, it depends on what we would want a =
typeef to *do*.  Eg, if it's just an alternate name, then maybe.  If, ho=
wever, typedefs allow other functionality -- such as validation, additio=
nal methods, etc. -- then primitive -> typeef is not a guaranteed total =
function.  Eg;

typedef UserId: string is /\s{3}-\s{4}/ {
  public function groupId(): string {
    return substr($this, 3);
  }
}

Maybe that particular functionality makes sense to do, maybe not, that's=
 a separate discussion.  My point for now is just that there are typedef=
 approaches where auto-up-casting would be frequently invalid, and proba=
bly also designs where auto-down-casting would be invalid (or possibly v=
alid).  For now, we should keep all options on the table until we decide=
 which options we want to make impossible.

>> In Go you cannot add or subtract on a typedef without casting to the=20
>> underlying type.  I would definitely prefer that to be relaxed, but o=
nly
>>  if it is relaxed via an explicit opt-in, e.g. something maybe like=20
>> this:
>>=20
>> typedef UserId: int operations: +, -, *, /;
>> typedef UserName: string operations: .;=20

Not to go further down this rabbit hole than is necessary, but I would m=
uch rather see operator overloads adopted, along the lines of Jordan's p=
revious RFC, and let typedefs implement that if them if sensible.

There's probably yet another research project to do here.  I'd volunteer=
, but I now have a newborn taking up most of my time. :-)

--Larry Garfield