On Mon, Aug 26, 2024, 12:02 PM Larry Garfield <la...@garfieldtech.com>
wrote:
> 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 can see a few others:
- string concatenation. I might want to prepend or append a string to a
default.
- fractional or multiplicative application, e.g. for durations/timeouts.
These might require testing for non-zero first as well.
- decorating a default instance (e.g. to lazily create a proxy without
knowing the default implementation used for an argument hinted against an
interface)
And these are just off the top of my head. I could likely identify more
with a short bit of time looking through some libraries I regularly use.
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.
>
IF it's possible to accomplish, I think it's better to identify the
"leaving this open will create WTF situations" than to prematurely lock
_everything_ down up front.
There's been a few good lists about the cool things this could enable,
demonstrating the value; maybe now we should focus on the "we absolutely
shouldn't enable" pieces to allow for broader consensus.
> 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
>
