Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125357
Feedback-ID: id5114917:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 30 Aug 2024 09:11:57 +0100
To: internals@lists.php.net
Message-ID: <bf70d866-8704-4de4-aa59-d2ff09916c7f@app.fastmail.com>
In-Reply-To: <fe37b0bc-af11-4209-94bd-c60db59671ff@scriptfusion.com>
References: <0c8ed5d6-5507-4c41-8d7f-05d14ba8aa4c@scriptfusion.com>
 <fe37b0bc-af11-4209-94bd-c60db59671ff@scriptfusion.com>
Subject: Re: [PHP-DEV] Re: [RFC] Default expression
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On Thu, 29 Aug 2024, at 22:52, Bilge wrote:
>> New RFC just dropped: https://wiki.php.net/rfc/default_expression. I 
>> think some of you might enjoy this one. Hit me with any feedback.
>>
> Now the dust has settled, I've updated the RFC to version 1.1. The 
> premise of the RFC is unchanged, but the proposal has been expanded and 
> a discussion section added to summarise the ~100 message thread to 
> capture the major concerns raised in a condensed format. I hope I've 
> done a good job of fairly and accurately representing your concerns, but 
> if not please correct me.

Hi,

I will try to find some time over the next few days to write something up, because there are some clear misunderstandings in that current text.

- It's not about union types. There are lots of examples using union types, because they're easier to illustrate than class/interface hierarchies, but "disallowing default to be passed to union types" wouldn't even help with the example directly below that sentence.
- The paragraph about "Default as a contract" misses the point by a mile. There's a world of difference between "the new version of this library has different behaviour" and "the new version of this library gives a TypeError in my code which used to work".
- It's not about "critics" and "preferred versions", or it doesn't need to be. We can say "here are some situations where it might be useful; and here are some situations where it would cause unexpected errors; do we think the benefits of one outweigh the cost/risk of the other?" 

I already shared this with you, but for the benefit of the wider audience, here are some examples I've put together of when users might vary the types of defaults, and how that would cause errors with the proposed feature: https://gist.github.com/IMSoP/16e2422d86e3ab513d6b0658009d0c06 I stress again, I'm not trying to win points in a popularity contest here, I'm trying to make sure we properly lay out the pros and cons of the proposal.

It's worth noting that the drawback being pointed out is similar to one encountered with named arguments. Nikita dedicated a substantial part of that RFC to discussing the problem, its possible solutions, and the impact of the proposed direction: this section https://wiki.php.net/rfc/named_params#parameter_name_changes_during_inheritance and this one https://wiki.php.net/rfc/named_params#to_parameter_name_changes_during_inheritance and most of this one https://wiki.php.net/rfc/named_params#backwards_incompatible_changes

Regards,
-- 
Rowan Tommins
[IMSoP]