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. Best, Jakob
