switch statements with empty parameters parameters

[Holo The Sage Wolf]

While the suggestion does violate SRP, it is not without reason. Java
currently doesn't have unrestricted conditional expression, switch without
parameter will solve this without much language complexity.
Kotlin has this in their `when` expression.

The feature you are suggesting is completely different and I don't think
the 2 features should be talked about in the same thread.

On Tue, 1 Oct 2024, 16:45 Brian Goetz, <brian.goetz at oracle.com> wrote:

> For those following along: Olexandr is appealing to a feature of C# where
> `< n` is a pattern which is applicable to numeric types, and matches when
> the inequality holds.  If we had such patterns, switch wouldn’t need to
> change.  (Such patterns are not currently on the roadmap, for a number of
> reasons but mostly because there are so many higher-value features ahead of
> it in the queue.).
>
> On Oct 1, 2024, at 9:39 AM, Olexandr Rotan <rotanolexandr842 at gmail.com>
> wrote:
>
> I would say that the moment there is something except i in switch you are
> violating SRP on statement level. If I were to advocate for alike feature,
> I would much rather support something like
>
>  var res = switch (i) {
>     case < 5 -> 5;
>     case > 10 -> 10;
>     case null -> 0
>     default -> throw new IllegalStateException("Unexpected value: " + new
> Object());
> };
>
> (something like this is present in .NET). Adding case ... j.length() < 10
> -> 20; seems like it steps outside of switch scope, which is pattern
> matching on switch argument, to me.
>
> Regrads
>
> On Tue, Oct 1, 2024 at 4:20 PM Brian Goetz <brian.goetz at oracle.com> wrote:
>
>> Yes, this has been considered several times.  It is one of those things
>> that seems clever at first, and it is not intrinsically flawed, but over
>> time seems less attractive, for a number of reasons.
>>
>> To start with, let’s recognize that `switch` doesn’t really need to
>> exist; it doesn’t express anything that we can’t express with `if` and
>> other control flows.  So why do we have it?  Because it is _more
>> constrained_ than arbitrary if-else-break logic, and therefore we can write
>> simpler programs with it.  If we give switch more kinds of jobs to do, we
>> risk giving up that simplicity benefit.
>>
>> The essence of switch is to ask “is this thing one of these, if so, do
>> the appropriate thing.”  It started out very limited (limited in selector
>> types and the kinds of cases), and we generalized it to more types and more
>> powerful cases (through patterns and guards), while at the same time,
>> retaining that essence of “pick one based on what this target is.”
>>
>> So the answer to your question is: yes, it’s been considered; yes, it’s
>> not totally dumb (many proposed language features don’t meet this bar); but
>> no, it does not seem the best thing we could be working on now.
>>
>>
>> On Oct 1, 2024, at 9:09 AM, mirage <newblood17 at gmail.com> wrote:
>>
>> Hello.
>>
>> In the recent years switch has been enhanced and there are some
>> discussions about enhancing it even further with try - catch evaluation
>> style inside the switch itself.
>>
>> i was wondering if an additional enhancement could be to be able to use
>> an empty parameter switch so we can use switch as a general-purpose
>> replacement of if-else chains. Switch has many advantages over if-else
>> chains, being these the most relevant.
>>
>> - The code it's cleaner and more readable, even with nested switch
>> expressions.
>> - Switch can be an expression, so it can return an assign a value to a
>> variable.
>>
>> nowadays we can use something like this.
>>
>> var i = someIntMethodParameter;
>> var j = someStringMethodParameter
>> var res = switch (new Object()){
>>     case Object _ when i < 5 -> 5;
>>     case Object _ when i > 10 -> 10;
>>     case Object _ when j.length() < 10 -> 20;
>>     case null -> 0;
>>     default -> throw new IllegalStateException("Unexpected value: " + new
>> Object());
>> };
>>
>> as we can see here this is effectively a replacement for if-else chains
>> that returns the first true case, but there are some problems with this
>> syntax and semantics
>>
>> . I was wondering if it could be a good idea to
>>
>> *
>> };*
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241001/d51af5f3/attachment.htm>