On Mon, Aug 26, 2024, at 6:36 AM, Jakob Givoni wrote:
> On Mon, Aug 26, 2024 at 12:49 PM Rowan Tommins [IMSoP]
> <imsop....@rwec.co.uk> wrote:
>> On Mon, 26 Aug 2024, at 10:14, Bilge wrote:
>> > You're absolutely right, I would be interested to see any viable patch
>> > that effectively implements a set of restrictions on how `default` may
>> > be used. Requesting it be done at the parser level was not meant as a
>> > gotcha, that's just how I (with my lack of experience) would have
>> > approached it, but certainly trapping cases in the compiler is equally,
>> > if not more valid and/or practical.
>>
>> Another approach that occurred to me was in the executor: rather than
>> evaluating to the default value immediately, "default" could resolve to a
>> special value, essentially wrapping the reflection parameter info. Then when
>> the function is actually called, it would be "unboxed" and the actual value
>> fetched, but use in any other context would be a type error.
>>
>> That would allow arbitrarily complex expressions to resolve to "default",
>> but not perform any operations on it - a bit like propagating sqrt(-1)
>> through an engineering formula where you know it will be cancelled out
>> eventually.
>>
>
> I 100% agree with this.
> "default" should not evaluate to a value before sending it as an
> argument to the function or method.
> I understand from what the RFC author wrote a while ago that doing so
> (evaluating to the actual default value using reflection) was the
> easier and perhaps only viable way at the moment, but if that's the
> case, I don't think the value of this RFC justifies doing something
> like that, which to me seems like a hack.
>
> For those already expressing interest in being able to modify a binary
> flag default parameter using this "trick", I still don't think it
> justifies this RFC. In my opinion, functions that accept multiple
> arbitrary options by compressing them into a binary flag have a badly
> designed interface to begin with.
>
> So, my 10c: Make "default" a pure keyword / immutable value if
> possible, or reconsider whether this feature is really worth the fuss.
The problem here is that `foo(default | ADDITIONAL_FLAG)` is so far the most
compelling use case I've seen for this feature. It's really one of only two I
see myself possibly using, frankly. So a limitation that would disallow that
pattern would render the RFC almost useless.
The other compelling case would be the rare occasions where today you'd do
something like this:
if ($user_provided_value) {
foo($beep, $user_provided_value);
} else {
foo($beep);
}
Which this RFC would allow to be collapsed into
foo($beep, $user_provided_value ?: default);
So far those are the two use cases I can realistically see being helpful, and I
acknowledge both are. I recognize that "limiting the allowed expression
structures arbitrarily is way harder than it sounds" is a valid argument as
well. At the same time, John C has offered some valid examples of cases where
it would open up additional footguns, and we want to minimize those in general.
Those shouldn't be ignored, either.
At the moment I'm on the fence on this RFC. I could go either way right now,
so I'm watching to see how it develops.
--Larry Garfield
