I never liked the #switch directive. There is about 15000 lines of FTL here: https://github.com/congo-cc/congo-parser-generator/tree/main/src/templates that I mostly wrote. It's part of the CongoCC parser generator. I just checked and there is not a single #switch directive in all of it. Not one. I just never use it. I guess I always use #if...#elseif.../#if. The reason there is a #switch directive in FreeMarker is because the original author of FreeMarker 1.x had it in there. (That would be from 1998 or thereabouts.) And (rightly or wrongly) when I took over FreeMarker development towards the end of 2001, I continued to have it, even though I said openly that I didn't like it.
You know, the main reason (AFAICS) that switch/case is appealing in C (and C++/Java etc) is because in a compiled language, you can translate this into a jump table that is, in principle, more efficient than if-elseif..else. Well, somewhat more efficient, probably not a significant difference usually. But that consideration does not apply to FreeMarker anyway. As for default fall-through, that's probably just a design mistake from way back that we're still living with -- though, as you point out, Go finally corrects that. On Sat, Feb 3, 2024 at 10:20 PM Simon Hartley <scrhart...@yahoo.co.uk.invalid> wrote: > If you leave the parent directive as switch, then there would need to be a > decision for what should happen if the user tries to mix option and case in > the same switch, i.e. should it "just work"? > > I did remember that JSP used choose/when/otherwise, so your previous > suggestion isn't without precedence. #option is as good as any (ahead of > #choice and #when ???), but here are some more random words anyway: #check, > #criterion, #test > I'm not 100% certain that there is any need for a #switch directive in a template language like FreeMarker. (As I said, I never use it myself.) Probably I should have axed it back in 2001! But, yes, one possibility would be to just get rid of it, or only support it in a backward compatibility mode maybe, and then consider whether to introduce some newer construct like #match or #choice or something like that, that is less problematic. > > Your idea for multiple values per case seemed like a nice upgrade. What > are your thoughts on "values" being expressions as I touched on in the > Future Work section? > Well, actually, having multiple values in a switch looks like a good idea. However, it also seems like a good idea to get rid of the switch with the error-prone fall-through, so... I think it would be better to have a newer construct that introduces these ideas and does not have the fall-through behavior. Well, just to tell you that you do have me thinking about it. I might implement something like this in FreeMarker 3 but then again, there are a lot of other pending issues, and I don't see this as having very high priority. Regards, Jon > > > > > > On Saturday, 3 February 2024 at 18:19:09 GMT, Daniel Dekany < > daniel.dek...@gmail.com> wrote: > > > > > > > <#switch value fallthrough="explicit"> > > With that it's at least clear which behavior we get, but then I guess it's > too verbose. > > > I would point out that Java switch expressions (not statements) don't > allow fall-through at all. > > I'm pretty confident that if we support multiple values per #case (or > whatever it will be called), then fall-through is just not worth the > trouble. > > > Java 21 Pattern Matching syntax > > That's unfortunate, as #when was high on my list. Though it's not in place > of "case" in Java, so it's maybe not that confusing if we have it in place > of #case. Anyway, how about #option then? > > <#switch contact.type> > <#option 'INDIVIDUAL', 'PROXY'> > ... > <#option 'ORGANIZATION'> > ... > <#default> > ... > </#switch> > > > On Sat, Feb 3, 2024 at 6:11 PM Simon Hartley <scrhart...@yahoo.co.uk > .invalid> > wrote: > > > 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 > > > > > > -- > Best regards, > Daniel Dekany >
