Expanding the "expression syntax"

[Red IO]

Yes I know this python syntax.
To make it clear saying that I'm not a fan of python would be an
understatement.
But even the python creator labeled the loop else as his biggest mistake.
And adding "the biggest mistake" of my least favorite language to java is
definitely not in my interest.

When you look in another direction like rust which already features the
"everything is an expression" mindset you can see that for and while loops
where purposefully left out because of this exact dilemma. Rust features a
special endless loop expression which can be an expression when static
analysis can confirm that "yield" will be hit eventually or loop forever.
But I don't see java adding this loop type and treating a "while(true)"
which is the practical equivalent specially would be weird.

Great regards
RedIODev

On Wed, Apr 5, 2023, 19:27 Adowrath <adowrath at protonmail.ch> wrote:

> Actually, regarding the `else` block/branch for a loop, there's almost a
> precedence for this in Python: for and while loops can have an `else` block
> that executes after the loop has finished, iff no break statement (or, of
> course, return) was hit inside of the loop, only that this doesn't elevate
> the loop to an expression. Using the same logic for yielding from an
> expression loop could work equally - the downside is that even in Python
> it's considered quite uncommon/unusual syntax.
>
> Regards,
> Adowrath
> Am 2023-04-05 um 19:17 schrieb Red IO:
>
> I actually tried this exactly with annotation processor "hacks" I then
> realized that a loop might execute 0 times or never conditionally hit a
> yield statements. This results in the expression sometimes not yielding a
> result which wouldn't allow an assignment to a final variable and confusing
> errors like "variable might not be initialized" the only solution would be
> to add an else block to a loop that os executed when no yield was hit in
> the loop body (which would be ugly and confusing in my opinion)
> That's why I stepped down from generalizing yield to all control flow
> elements to specially allow yield in try.
>
> Great regards
> RedIODev
>
> On Wed, Apr 5, 2023, 16:27 Holo The Sage Wolf <holo3146 at gmail.com> wrote:
>
>> A different approach is to give `yield` the same semantics as `break`,
>> and interpreting `break label` as `yield label null`, this would make all
>> label blocks be expressions.
>>
>> The only thing we need to be careful with is finally block, but this
>> situation already happens with `return` inside of a finally block, so I
>> don't think we need to handle this situation differently
>>
>> On Wed, Apr 5, 2023, 15:55 Tagir Valeev <amaembo at gmail.com> wrote:
>>
>>> Hello!
>>>
>>> Just for the record, three years ago I posted a similar, though more
>>> universal proposal, "do expressions":
>>>
>>> https://mail.openjdk.org/pipermail/amber-spec-experts/2020-March/002046.html
>>>
>>> With best regards,
>>> Tagir Valeev.
>>>
>>> On Wed, Apr 5, 2023 at 11:58 AM Red IO <redio.development at gmail.com>
>>> wrote:
>>>
>>>> I did some more research and testing and concluded that loop
>>>> expressions are more difficult to achieve than I thought and are not as
>>>> simple as I thought.
>>>> So I limit my proposal to try expressions since I really think they are
>>>> worth it.
>>>> A try expression would follow this syntax:
>>>> TARGET VARIABLE = TRY_KEYWORD [RECOURSE_BLOCK] TRY_BODY(with every path
>>>> leading to a yield or throw) [CATCH_BLOCKS(with also a yield or throw in
>>>> every path)]
>>>> [FINALLY_BLOCK (with no yield but throw possible)];
>>>>
>>>> An example would be:
>>>> int fileInt = try (var reader = new BufferedReader(new
>>>> FileReader("test.txt"))) {
>>>> var line = reader.readLine();
>>>> if (line == null)
>>>> yield -1;
>>>> yield Integer.parseInt(line);
>>>> } catch (IOException e) {
>>>> throw new CustomException("Couldn't open file", e);
>>>> } catch (NumberFormatException e) {
>>>> yield -1;
>>>> } finally {
>>>> if (outsideCondition)
>>>> throw new CustomCancelledExecption();
>>>> System.out.println("file read done");
>>>> };
>>>>
>>>> This example is constructed to feature all possible parts of the syntax
>>>> and is not necessarily code that makes sense to write.
>>>>
>>>> Great regards
>>>> RedIODev
>>>>
>>>> On Sat, Mar 4, 2023, 10:55 Red IO <redio.development at gmail.com> wrote:
>>>>
>>>>> Currently we have the switch expression as the only expression
>>>>> returning a result.
>>>>> Example:
>>>>> boolean b = switch (1) {
>>>>> case 0 -> false;
>>>>> case 1 -> {
>>>>> yield true;
>>>>> }
>>>>> };
>>>>>
>>>>> The idea would be to expand this syntax to different expressions for
>>>>> example the try expression:
>>>>>
>>>>> int i = try {
>>>>> yield Integer.parseInt("Abc");
>>>>> } catch (NumberFormatException e) {
>>>>> yield -1;
>>>>> };
>>>>>
>>>>> Or loops:
>>>>>
>>>>> String searched = for(String s : args) {
>>>>> if (s.startsWith("-"))
>>>>> yield s;
>>>>> };
>>>>>
>>>>> The idea is to make all java control flow expressions able to yield a
>>>>> value.
>>>>>
>>>>> Among many new patterns possible like the examples above it would for
>>>>> example "clean up" the exception catching initialization:
>>>>>
>>>>> Foo foo = null;
>>>>>
>>>>> try {
>>>>> foo = new Foo();
>>>>> } catch (SomeException e) {
>>>>> //do something or nothing
>>>>> } finally {
>>>>> //maybe change the value again
>>>>> }
>>>>>
>>>>> To
>>>>>
>>>>> var foo = try {
>>>>> yield new Foo();
>>>>> } catch (SomeException e) {
>>>>> //throw or yield
>>>>> } finally {
>>>>> //throw or do nothing
>>>>> };
>>>>>
>>>>> Another benefit especially in this example is the clearer state of the
>>>>> result. In an yielding expression you have to either yield or throw. Also
>>>>> subsequent manipulation in for example the finally block is not possible
>>>>> making the source of the returned result clear to identify.
>>>>>
>>>>> Great regards
>>>>> RedIODev
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230405/3be30f8b/attachment.htm>