Hi, thanks for your work of clearing the mist. Am Donnerstag, dem 30.03.2023 um 11:03 +0200 schrieb Arnaud Spiwack:
1. Have we missed some use-cases, if so describe? (I'm sure we have, so I'd be surprised if nothing turns up here)
Another reason, mostly for completeness, is X. Programmers use extensions to _refer_ to a particular feature when talking/writing/searching about it. They give names to concepts that might not have an obvious canonical name otherwise. Imagine LambdaCase did not have that name; it would be slightly harder to talk about it. --- Since your point 1 has an explicit list of reasons why an extension is no on by default (“experimental or unstable”, with the word “early” signaling that this status is expected to change) I wonder if we need more points for “Developer wants access to features not on-by-default for some other reasons”. In fact, you list some more reasons (4/5 – deprecated, 7 – not backward compatible, 8 – perf impact), but the list seems incomplete. For example RecordWildCards doesn’t seem to be experimental, unstable, deprecated or perf impacting to me. Nor does UnicodeSyntax. So it’s not clear to me if you meant to put them under 1 (and “experimental and unstable” needs to be extended) or under extra bullets.
From a user-point of view, it seems you could possible merge 1, 4, 5, 6, 7 and 8 as “Developer wants access to features not on by default”. The developer probably doesn’t really care _why_ the extension is not on by default, they just want to use it when they want to use it :).
And then the question of why an extension is not on by default (present, past, future…) would be separate from that. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/