#else and #ifelse have no closing tag either. Nor does #recover. That's the style that was chosen back then. Brevity over correctness(?).
<#on .other> would be rather strange. "Why don't they just have a keyword for the statement itself???". Also, developers won't invest much mental energy into learning a template language, so, the less surprising, the better. On Sat, Feb 10, 2024 at 9:45 AM Denis Bredelet <brede...@mac.com.invalid> wrote: > Hi > > Understood. > > > > One argument for supporting #break in #on: whitespace avoidance > > > > Because there's not an explicit closing tag for #case or #on, the use of > #break in the following avoids a trailing newline: > > <#switch x> > > <#case 1>1<#break> > > <#default>not 1<#break> > > </#switch> > > 1. #on should have a close tag, for that reason. > 2. #break should work as normal inside #on. That is to allow exiting an > #on directive early, for example on a condition. > 3. #case should not be allowed together with #on > > I don’t know if #default should be replaced as well when using #on (it > doesn’t have a close tag!) > I suggest <#on .other> > > Cheers, > — Denis. > > > > > Do we just say that if they need that then they should use #case > instead? It could mean that we'd never we able to fully deprecate #case. > > > > --- > > Many thanks, > > Simon Hartley > > > > > > On Friday, 9 February 2024 at 23:29:28 GMT, Daniel Dekany < > daniel.dek...@gmail.com> wrote: > > > > > > > > > > > > Because both #switch and #list supports #break, of course it will break > out > > from the innermost one (whether it's a #switch, or a #break). > > > > #continue should only work with #list, however, it seems there's a bug > > here, and indeed, inside #switch it does the same as #break (that it's > > certainly present for 20 years or so). > > > > As of #on, we just don't care about #break, it's unsupported. So it > should > > only affect #list. Similarly as #continue should work... We can't really > > fix that anymore for #case (or only with incomplatible_improvements... > > yeah, annoying), but for #on, we can fix that. > > > > I say, we don't want to support mixing #case and #on in the same #switch. > > To keep things as simple as possible... (Well, if we want to do > > anything with #switch at all.) > > > >> On Fri, Feb 9, 2024 at 11:36 PM Simon Hartley > >> <scrhart...@yahoo.co.uk.invalid> wrote: > >> > >> I've looked into adding #on support to #switch and I think the following > >> needs further consideration: how #break works in #switch with #on? > >> > >> When using #switch with #case in a #list, #break finds the #switch and > >> breaks out of that, rather than the #list. > >> <#list [1,2,3] as item> > >> <#switch item> > >> <#case 2> It's 2 <#break> <!-- Breaks from #switch, not #list > --> > >> <#default> Not 2 > >> </#switch> > >> </#list> > >> > >> Mixing #list with #on, what's the behavior? > >> 1. #break is in a #switch and so it breaks from that > >> 2. #break is in an #on and so throws an error because #on does not allow > >> that > >> 3. #break acts like it's used by #list and so breaks from that, rather > >> than the #switch > >> <#list [1,2,3] as item> > >> <#switch item> > >> <#on 2> It's 2 <#break> <#-- break from #switch, break from > #list > >> or throw error? --> > >> <#default> Not 2 > >> </#switch> > >> </#list> > >> > >> > >> P.S. > >> It seems that #switch currently doesn't distinguish between #break and > >> #continue. As a result, the following treats #continue as if it's a > #break, > >> rather than skipping to the next item in the #list. > >> > >> <#list [1,2,3] as item> > >> <#switch item> > >> <#case 2> > >> ${item} > >> <#continue> > >> <#default> > >> ${item} > >> </#switch> > >> After > >> </#list> > >> The output is: > >> 1 > >> After > >> 2 > >> After > >> 3 > >> After > >> > >> Rather than: > >> 1 > >> After > >> 2 > >> > >> > >> --- > >> Best regards, > >> Simon Hartley > >> > >> > >> > >> > >> > >> > >> On Monday, 5 February 2024 at 23:21:13 GMT, Daniel Dekany < > >> daniel.dek...@gmail.com> wrote: > >> > >> > >> > >> > >> > >> #on is maybe better than #option... I'm not a native english speaker > >> though, so I'm nor entirely sure. > >> > >> Someone else asked what if it's mixed with #case. I would just disallow > >> that. > >> > >> And of course, with #on (or #option) there would be no fall though at > all. > >> Since we have multiple values per #on, there's almost no use-case for > it. > >> > >> On Tue, Feb 6, 2024 at 12:11 AM Denis Bredelet <brede...@me.com.invalid > > > >> wrote: > >> > >>> Hello, > >>> > >>> Good suggestions here. I think #option works well. > >>> > >>> You could also use #switch … #on … #on … > >>> > >>> If you want to keep #case and add a modifier, I suggest break=req (the > >>> default, #break is required to exit the #switch) and break=opt (#break > >> only > >>> required when you want to exit the #case early). > >>> > >>> Cheers > >>> — Denis. > >>> > >>>> On 3 Feb 2024, at 21:20, 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 > >>>> > >>>> 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? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> 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 > >>> > >> > >> > >> -- > >> Best regards, > >> Daniel Dekany > >> > > > > > > -- > > Best regards, > > Daniel Dekany > -- Best regards, Daniel Dekany