On Sun, Aug 25, 2024, at 10:29 AM, Bilge wrote: > On 25/08/2024 14:35, Larry Garfield wrote: >> The approach here seems reasonable overall. The mental model I have from >> the RFC is "yoink the default value out of the function, drop it into this >> expression embedded in the function call, and let the chips fall where they >> may." Is that about accurate? Yes, as it happens. That is the approach we >> took, because the alternative would have been changing how values are sent >> to functions, which would have required a lot more changes to the engine >> with no clear benefit. Internally it literally calls the reflection API, but >> a low-level call, that elides the class instantiation and unnecessary hoops >> of the public interface that would just slow it down. My main holdup is the >> need. I... can't recall ever having a situation where this is something I >> needed. Some of the examples show valid use cases (eg, the "default plus >> this binary flag" example), but again, I've never actually run into that >> myself in practice. That's fine. Not everyone will have such a need, and of >> those that do, I'm willing to bet it will be rare or uncommon at best. But >> for those times it is needed, the frequency by which it is needed in no way >> diminishes its usefulness. I rarely use `goto` but that doesn't mean we >> shouldn't have the feature. My other concern is the list of supported >> expression types. I understand how the implementation would naturally make >> all of those syntactically valid, but it seems many of them, if not most, >> are semantically nonsensical. Eg, `default > 1` would take a presumably >> numeric default value and output a boolean, which should really never be >> type compatible with the function being called. (A param type of int|bool >> is a code smell at best, and a fatal waiting to happen at worst.) In >> practice, I think a majority of those expressions would be logically >> nonsensical, so I wonder if it would be better to only allow a few >> reasonable ones and block the others, to keep people from thinking >> nonsensical code would do something useful.
> Since you're not the only one raising this, I will address it, but just > to say there is no good reason, in my mind, to ever prohibit the > expressiveness. To quote Rob > >>I'm reasonably certain you can write nonsensical PHP without this feature. I >>don't think we should be the nanny of developers. See, I approach it from an entirely different philosophical perspective: To the extent possible, the language and compiler should prevent you from doing stupid things, or at least make doing stupid things harder. This is the design philosophy behind, well, most good user interfaces. It's why it's good that US and EU power outlets are different, because they run different voltages, and blindly plugging one into the other can cause damage or death. This is the design philosophy behind all type systems: Make illogical or dangerous or "we know it can't work" code paths a compile error, or even impossible to express at all. This is the design philosophy behind password_hash() and friends: The easy behavior is, 99% of the time, the right one, so doing the "right thing" is easy. Doing something dumb (like explicitly setting password_hash() to use md5 or something) may be possible, but it requires extra work to be dumb. Good design makes the easy path the safe path. Now, certainly, the definition of "stupid things" is subjective and squishy, and reasonable people can disagree on where that threshold is. That's what a robust discussion is for, to figure out what qualifies as a "stupid thing" in this case. Rob has shown some possible, hypothetical uses for some of the seemingly silly possible combinations, which may or may not carry weight with people. But there are others that are still unjustified, so for now, I would still put "default != 5" into the "stupid things" category, for example. As you've noted, this is already applicable only in some edge cases to begin with, so enabling edge cases of edge cases that only maybe make sense if you squint is very likely in the "stupid things" territory. > I fully agree with that sentiment. It seems to be biting me that I went > to the trouble of listing out every permutation of what *expression* > means where perhaps this criticism would not have been levied at all > had I chosen not to do so. >From one RFC author to another, it's better to make that list explicitly and >let us collectively think through the logic of it than to be light on details >and not realize what will break until later. We've had RFCs that did that, >and it caused problems. The discussion can absolutely be frustrating (boy do >I know), but the language is better for it. So I'm glad you did call it out >so we could have this discussion. --Larry Garfield
