> <#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
