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
