Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

For the record: I checked IDEA Ultimate source code (>10 of Java files, total size is about 400Mb). It appears that an unqualified call of the method called 'yield' as an expression statement is used only once accross our sources:

Re: Draft language spec for JEP 355: Text Blocks

I wonder if we want to be cagey about committing to interning, which is another way to say we must translate too a constant string info. In the future, alternate condy- based representations may seem desirable and we don’t want to be painted into a translation by overspecification. Sent

Draft language spec for JEP 355: Text Blocks

Please see http://cr.openjdk.java.net/~abuckley/jep355/text-blocks-jls.html for JLS changes that align with the JEP. Text blocks compile to the same class file construct as string literals, namely CONSTANT_String_info entries in the constant pool. Helpfully, the JVMS is already agnostic

Re: Call for bikeshed -- break replacement in expression switch

On May 17, 2019, at 4:06 PM, Alex Buckley wrote: > > the decision still has to be taken about whether "in a SwitchLabeledBlock" or > "in " is the proper context to recognize something new. From Tagir's note it seems we want to use less context than "in a SLB", because IDEs (and human eyes)

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

Okay, with this more detailed explanation and understanding, I am back in the `yield` camp. But I’m glad to have explored that side path just a bit. > On May 20, 2019, at 3:51 PM, Brian Goetz > wrote: > > Clarification on Option (B): the rational thing to do is

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

On May 20, 2019, at 12:51 PM, Brian Goetz wrote: > > The cost-benefit analysis rests on the assumption that this will bite > exceedingly rarely, and when it does, the workaround will be clear and easy. OK, so let's road-test "yield". While "break: x" is syntactically safer than "yield x", I

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

On May 20, 2019, at 8:24 AM, Tagir Valeev wrote: > > Assuming that we agreed on 'yield' the option B seems the most attractive. A > big No to context-specific parse tree. It's a complete pain to IDEs. Don't > forget that IDE often deals with incomplete code, missing dependencies, etc., > and

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

Clarification on Option (B): the rational thing to do is probably not to restrict this behavior to switchy blocks, because there are other kinds of statement contexts that will be embedded in switchy blocks, such as: case L -> { if (cond) yield e; } And surely we

Re: Yield as contextual keyword

On 5/20/19 1:02 PM, John Rose wrote: > On May 20, 2019, at 9:06 AM, Guy Steele wrote: >> >> under this theory a plausible spelling of `break-with` is `break:` > > FWIW I'd be very very happy with the look/feel of `break: x;`. > Almost the same here. Subtract a few verys, keep the happy. -Doug

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

On May 20, 2019, at 9:06 AM, Guy Steele wrote: > > under this theory a plausible spelling of `break-with` is `break:` FWIW I'd be very very happy with the look/feel of `break: x;`. I'd be a little happier with `break->x` because I'm used to reading expressions `x` in `->x` but not so much

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

> On May 20, 2019, at 12:16 PM, Brian Goetz wrote: > >> But I now think that this argument is weak, because I believe it is in fact >> unlikely that there will be a large number of other statement types that we >> will want to turn into expressions. >> >> * Yes, we may want block

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

> But I now think that this argument is weak, because I believe it is in fact > unlikely that there will be a large number of other statement types that we > will want to turn into expressions. > > * Yes, we may want block expressions. > * We would want `if`-statement expressions

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

I am becoming more worried again about the consequences of using a contextual keyword such as “yield”, especially for IDEs. It seems to me that this whole discussion kicked off with a discussion of `yield` as being desirable because, by analogy with `return` being the One True Way to return a