On Mon, Aug 26, 2024 at 12:49 PM Rowan Tommins [IMSoP] <[email protected]>
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.
Best,
Jakob