Re: Records: construction and validation

On 03/12/2018 01:48 PM, Brian Goetz wrote: Here's a sketch of where our thinking is right now for construction and validation. General goal: As Kevin pointed out, we should make adding incremental validation easy, otherwise people won't do it, and the result is worse code.  It should be

Re: Records -- current status

On 3/16/2018 5:59 PM, Kevin Bourrillion wrote: On Fri, Mar 16, 2018 at 2:28 PM, Brian Goetz > wrote: But also, there are times when matching against the abstract type makes sense too.  For example, if you want to traverse the

Re: Records -- current status

 - Extension.  The proposal outlines a notion of abstract record, which provides a "width subtyped" hierarchy.  Some have questioned whether this carries its weight, especially given how Scala doesn't support case-to-case extension (some see this as a bug, others as an

Re: Records -- current status

On Fri, Mar 16, 2018 at 11:55 AM, Brian Goetz wrote: There are a number of potentially open details on the design for records. > My inclination is to start with the simplest thing that preserves the > flexibility and expectations we want, and consider opening up later as

Re: Records -- current status

On 3/16/2018 4:45 PM, Remi Forax wrote:  - Mutability and accessibility.  I'd like to propose an odd choice here, which is: fields are final and package (protected for abstract records) by default, but finality can be explicitly opted out of (non-final) and accessibility can be explicitly

Re: Records -- current status

Hi Brian, - Mail original - > De: "Brian Goetz" > À: "amber-spec-experts" > Envoyé: Vendredi 16 Mars 2018 19:55:19 > Objet: Records -- current status > There are a number of potentially open details on the design for >

Records -- current status

There are a number of potentially open details on the design for records.  My inclination is to start with the simplest thing that preserves the flexibility and expectations we want, and consider opening up later as necessary. One of the biggest issues, which Kevin raised as a must-address

Switch expressions -- next steps

Without cutting off useful discussions in progress, it seems to me that we've reached a point where the design decisions for JEP 325 are largely stabilized and there's a prototype available that implements this design point.  (Much of the recent discussion, especially on nulls and

Re: break seen as a C archaism

> On Mar 16, 2018, at 5:39 AM, Peter Levart wrote: > > Expanding on do… Well, as long as we are fantasizing: > On 03/16/18 09:50, Peter Levart wrote: >> And if "while (false)" could be optional, we get: > > Or better yet, make "while (true)" optional even in statement

Re: break seen as a C archaism

I don't know why others find break so archaic. When I 1st saw this proposal, I thought that break was very intuitive choice for e-switch. I think this is mostly an emotional reaction.  There are plenty of things to dislike about switch in Java; I think that for some, the prospect of

Re: break seen as a C archaism

Hi Peter, I think this have been ruled out but Brian saying that we do not want to add a block that ends with an expression in Java. And i think we can use parenthesis to avoid to re-interpret what a int value = do( int x = foo(); break x * x; ); If we go in that direction, i think i

Re: break seen as a C archaism

Expanding on do... On 03/16/18 09:50, Peter Levart wrote: And if "while (false)" could be optional, we get: Or better yet, make "while (true)" optional even in statement do, so we can finally get away with some more boilerplate: for (;;) { } or while (true) { } and simply do: do { }

Re: break seen as a C archaism

Hi, May I jump in as an outsider and someone who's just using the language... On 03/15/18 22:58, John Rose wrote: On Mar 15, 2018, at 2:13 PM, Maurizio Cimadamore > wrote: So, from a language design perspective, 'return