Re: [records] Ancillary fields

On April 18, 2018 8:39:12 PM UTC, Brian Goetz wrote: > > >> Ahh, you missed the `lazy` keyword on there :-) Which is good because > >> it raises an issue: when you forget it, bad performance may result >> without other observable consequence. Although, it's already the

Re: [records] Ancillary fields

Ahh, you missed the `lazy` keyword on there :-) Which is good because it raises an issue: when you forget it, bad performance may result without other observable consequence. Although, it's already the case that reading code like the above ought to raise all kinds of alarm bells (e.g., now

Re: JEP325: Switch expressions spec

All good points.  Minor comments inline. |Were we considering allowing `case /something/, default:` or `default, case /something/:`? Of course you would never ever actually /need/ this... except in the one case that /something/ is null. In a switch expression it would be sad to be forced to

Re: [records] Ancillary fields

For primitives, you can always force yourself to use Integer:     lazy Integer i = f(); and make sure f() never returns null.  You can do something similar with a library class (e.g., Optional) for references.  So there are surely _safe_ ways to do it, albeit ugly ones. I kind of prefer to