Thank you.
> On May 21, 2019, at 4:41 PM, Alex Buckley wrote:
>
> On 5/21/2019 5:30 AM, Jim Laskey wrote:
>> TextBlock:
>>
>> " " " { the ASCII SP character } LineTerminator { TextBlockCharacter } " " "
>>
>> "the ASCII SP character" in the open delimiter is currently
>> implemented as any "w
On 5/21/2019 5:51 AM, Brian Goetz wrote:
As string literals get longer, the cost-benefit of interning get
worse, and eventually turn negative; it is super-unlikely that two
compilation units will use the same 14-line snippet of JSON (no
benefit), and at the same time, we’re taking up much more sp
On 5/21/2019 5:30 AM, Jim Laskey wrote:
TextBlock:
" " " { the ASCII SP character } LineTerminator { TextBlockCharacter } " " "
"the ASCII SP character" in the open delimiter is currently
implemented as any "white space" but not a line terminator. Later on you
state "zero or more white spaces
I discussed this with colleagues and can confirm that for IntelliJ
IDEA parser it will be no problem to always consider yield as a
statement. At least it's much easier than to consider it as a
statement inside switchy blocks only.
With best regards,
Tagir Valeev.
On Tue, May 21, 2019 at 12:38 PM
I think I’m saying something slightly stronger than that. Interning provides
two benefits:
- performance/footprint — not filling the heap up with a million instances of
“” or “yes”
- guarantees about String== — that it is safe to use == on String instances
I believe the value of the second i
Looks pretty good.
___
TextBlock:
" " " { the ASCII SP character } LineTerminator { TextBlockCharacter } " " "
"the ASCII SP character" in the open delimiter is currently implemented as any
"whi
Tagir,
These scenarios were considered in the decision, and I guess will be part of
the rationale section of some doc TBA.
The argument for removal of trailing white space is pretty close to the
argument for normalization of line terminators. The developer needs to be able
to rely on what the
