Expanding the "expression syntax"

Red IO redio.development at gmail.com
Wed Apr 5 17:17:54 UTC 2023


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/ed3958b5/attachment.htm>


More information about the amber-dev mailing list