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 don't know if this is practical - I'm not sure how that special value would be represented - but I thought I'd mention it in case it sparks further ideas.
