Cool. Just to cover all bases, what about the switch behavior remaining the same unless you opt-in using something like: <#switch value fallthrough="explicit"> Would you still rather not add the mental overhead of such modal behavior? Given your reaction to Go's choice, I assume you'd rather not do that. I would point out that Java switch expressions (not statements) don't allow fall-through at all. (There is a compile error if you try to use the block syntax that doesn't contain a yield and without the block syntax then the yield is implicit.)
If we went the new directive route, should it allow fall-through at all? Naming with a new directive may require care, since when clauses are part of Java's new Java 21 Pattern Matching syntax and so may lead to higher expectations. (see: https://docs.oracle.com/en/java/javase/21/language/pattern-matching-switch-expressions-and-statements.html#GUID-A5C220F6-F70A-4FE2-ADB8-3B8883A67E8A) On Saturday, 3 February 2024 at 09:44:38 GMT, Daniel Dekany <daniel.dek...@gmail.com> wrote: I'm not against addressing the core issue, but the only practical way I can imagine is with different directive names. Breaking existing templates is out of the question. It can't be a configurable behavior either, because then if you just look at a template, you can't be sure what will actually happen. Consider answering SO questions like that, or copy-pasting template snippets from elsewhere. What Go did is just wrong, IMAO. They had to find a different name to avoid confusion, like choice/when, or whatever. Same goes for FM. On Fri, Feb 2, 2024 at 2:38 AM Simon Hartley <scrhart...@yahoo.co.uk.invalid> wrote: > The below is structured as a proposal, but at the moment I just want to > gather opinions and also see if this a non-starter or not. It includes > options for adopting this in version 2 or the theoretical version 3. > Putting dev effort aside for the time being, is this a reasonable thing to > address and does it align with the desired approach? > > > ## Summary ## > > Enhance the switch directive to not force fall-through behavior. Using > switch is currently clunky and the available alternatives have their own > compromises. It should not exist in its current form in the next major > release. > > ## History ## > > The FreeMarker switch directive mimics the Java switch statement. It > supports fall-through and this is the control flow unless break is > encountered. The manual recommends against this directive due to this > error-prone behavior. Later, the switch built-in was added which does not > have the concept of fall-through. > > ## Goals ## > > * Avoid unnecessary syntactic noise caused by having to use the break > directive > > * Avoid accidental fall-through by making it explicit when needed > > ## Motivation ## > > * Avoid the potential for repetition due to elseif as a replacement > > * Offer increased syntactic clarity compared to the built-in > > * Avoid the pitfalls of the current switch directive > > > ## Description ## > > The basis of this proposal is inspired by the switch statement in the Go > language (see https://yourbasic.org/golang/switch-statement/). Rather > than the default being to fall-through and you have to use the break > keyword to avoid it, instead the default is to not fall-through and you > have to use the fallthrough keyword to get that behavior. Having explicit > fall-through stops it being a pitfall whilst allowing the feature to be > used if required. Go has avoided repeating the mistake of previous > languages and presents a solution that seems obvious in hindsight. > > Approaches for adopting this could be: > > * Replace the switch directive in the next major version with the explicit > fall-through version > > * Introduce a new switch directive with a new name > > * Have a global setting for which switch directive is used / available to > templates > > * Add an optional parameter to the switch directive for whether it should > fall-through or not; its default would be a config setting. If we did this > perhaps we should consider in future being able to parse the switch's value > parameter as optional (defaulting to true), taking further inspiration from > Go. > > If we want fall-through to be explicit, it makes sense to add a > fallthrough directive to act as the inverse of the break directive. The > user would then use the break directive (as required) when using the > current mode/directive for fall-through and the fallthrough directive (as > required) when using the new mode/directive. For what should happen when > using break in the new mode/directive and fallthrough in the old > mode/directive: it could either be an error, or break will still break and > fallthrough will do nothing (or perhaps go to the next case). > > > ## Alternatives ## > > * Remove the switch directive altogether > > * Completely disallow fall-through and the break directive (have neither > implicit nor explicit fall-through) > > * Add a more powerful match directive that supports pattern matching and > takes inspiration from e.g. Java's switch expressions or Rust's pattern > syntax > > ## Future work ## > > Reinstating switch as a first-class directive would open the door to > allowing enhancements to it again. > > One (low hanging?) example: for a case directive's value parameter to be > an expression it sometimes requires wrapping the expression in brackets > (e.g. it doesn't for an equality comparison, but does for a greater than > comparison); the parser could be enhanced to remove this requirement. > > > --- > Best regards, > Simon Hartley > -- Best regards, Daniel Dekany
