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.