#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
