Re: Named parameters [was: Re: Reader mail bag]

e otherwise. cheers, Rémi - Mail original - De: "Brian Goetz" <brian.go...@oracle.com> À: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> Envoyé: Jeudi 30 Novembre 2017 19:29:41 Objet: Reader mail bag We've gotten two submissions to the amber-sp

Switch expressions -- some revisions

After reviewing the feedback on the proposal for switch expressions, and a bit of going back to the drawing board, I have some proposed changes to the plan outlined in the JEP. 1.  Throw expressions.  While throw expressions are a reasonable feature, many expressed concern that if

Re: Switching on float/double/long

that, use bits representation for float and double, this is typically the kind of things that a user can also do with a record (a value type record ?) and a deconstructor, so in my opinion, we should not rush to implement this kind of switch given that we will soon provide a general me

Re: default branch placement in switch

uot;), we relax the above rule regarding default. On 12/11/2017 2:15 PM, Brian Goetz wrote: The middle is surely awful.  Though in the JDK, we have a fair number of uses where default is the _first_ case, which isn't unreasonable, and some might argue is even clearer in some cases. The reas

Re: Switching on float/double/long

?) and a deconstructor, so in my opinion, we should not rush to implement this kind of switch given that we will soon provide a general mechanism to implement them outside of the JDK. Rémi *De:*"Brian

Re: default branch placement in switch

regarding default. On Dec 14, 2017, at 2:39 PM, Brian Goetz <brian.go...@oracle.com <mailto:brian.go...@oracle.com>> wrote: Here's where I think we should come down on this. First, we should appeal to the general rule about pattern ordering; if pattern X dominates Y (that is, eve

Re: Switch expressions -- some revisions

So we dusted off an old idea, which we'd previously explored but which had some challenges, which is to use "break" with an operand instead of "return" to indicate local return in switch expressions.  So:     int y = switch(abs(x)) {     case 1 -> 1;    

Re: Switch expressions -- some revisions

The "return/return e/break/break e" analogy Brian just gave helps as well. My take-away from Kevin's reaction is: some will immediately see how "break n" is just a generalization of existing break, and some people will not immediately see it -- and when you don't, it feels uncomfortable.

Re: New JEP: Switch Expressions for the Java Language

On 12/18/2017 4:16 PM, Kevin Bourrillion wrote: On Mon, Dec 11, 2017 at 11:28 AM, Brian Goetz <brian.go...@oracle.com <mailto:brian.go...@oracle.com>> wrote: I think most of my questions surround how these changes will (or /should/) affect non-expression switches.

Re: Switch expressions -- some revisions

I think there are good arguments on both sides of this issue. Because, expression switch and statement switch, they have both commonality and difference. Overall, my gut sense is that "lumping" is better than "splitting" here.  Especially as there are so many possible dimensions of lump vs

Re: Switch expressions -- some revisions

ave been part of the code in the preceding box. On Dec 19, 2017, at 2:40 PM, Brian Goetz <brian.go...@oracle.com <mailto:brian.go...@oracle.com>> wrote: I've updated the JEP to reflect these proposed changes: https://bugs.openjdk.java.net/browse/JDK-8192963 On 12/14/2017 4:22 PM, B

Re: Switch expressions -- some revisions

I've updated the JEP to reflect these proposed changes:     https://bugs.openjdk.java.net/browse/JDK-8192963 On 12/14/2017 4:22 PM, Brian Goetz wrote: After reviewing the feedback on the proposal for switch expressions, and a bit of going back to the drawing board, I have some proposed

Re: PM design question: Scopes

On 11/20/2017 1:33 PM, Guy Steele wrote: I like this.  One question: what does this new theory have to say about the situation switch (x) {   case Foo(int x): int y = x; // fall through   case Bar(int x, int y): … } In this case, I would say that the second y is shadowing the first, and

Re: Local variable inference and anonymous class

This is like using an Object[], but with names and no second level of boxing… > On Nov 16, 2017, at 4:10 AM, John Rose wrote: > > On Nov 15, 2017, at 5:15 PM, Remi Forax > wrote: >> >>List list = List.of("hello",

Survey on primitive type test patterns

You may have seen a survey float by a few days ago, aimed at probing at developer intuition about the semantics of primitive type test patterns. The results are here, with over 1000 answers: https://www.surveymonkey.com/results/SM-87Y6K3BY8/ BACKGROUND The real goal of this survey was

Data classes

At the following URL, please find a writeup containing our current thoughts on Data Classes for Java: http://cr.openjdk.java.net/~briangoetz/amber/datum.html Comments welcome! We'll be making a prototype available soon for folks to play with.

Re: Data classes

This looks great! One thing springs to mind with the accessors: Is it possible that the generated accessor methods could participate in the implementation of interfaces? For example: interface Vector { double x(); double y(); double z(); } __data class Vector3

Re: Data classes

several other mails on each sections later. cheers, Rémi - Mail original - De: "Brian Goetz" <brian.go...@oracle.com> À: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> Envoyé: Mercredi 1 Novembre 2017 19:53:40 Objet: Data classes At the foll

Re: Data classes

In the proposal, you discuss about adding keywords like "non-final, unfinal, mutable", i.e. considering that there can be a different set of keywords for data class declaration which is different from the one we have on fields. In that spirit, we can have a flag like nullable, maybenull, etc

New JEP: Switch Expressions for the Java Language

We've separated out a package of standalone improvements to `switch` (switch expressions, case null, and case alternation) into their own JEP:     https://bugs.openjdk.java.net/browse/JDK-8192963

Re: New JEP: Switch Expressions for the Java Language

t y) { return switch(x) { case 0 -> y; // is it allowed, how is it translated ? default -> 0; }; } regards, Rémi - Mail original ----- De: "Brian Goetz" <brian.go...@oracle.com> À: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> Envoyé:

Re: New JEP: Switch Expressions for the Java Language

On 12/7/2017 6:28 PM, Liam Miller-Cushon wrote: I don't see it mentioned in the JEP, but will the default case of an expression switch be required to be last? (Previously: http://mail.openjdk.java.net/pipermail/amber-spec-observers/2017-November/000134.html) We've not fully worked through

Re: compareTo and deriving

/2017 10:12 AM, fo...@univ-mlv.fr wrote: - Mail original - De: "Brian Goetz" <brian.go...@oracle.com> À: "Remi Forax" <fo...@univ-mlv.fr>, "amber-spec-experts" <amber-spec-experts@openjdk.java.net> Envoyé: Lundi 4 Décembre 2017 15:54:1

Switch translation, part 1

This doc covers some groundwork on rationalizing existing translation of switch as we move towards pattern-enabled switches. # Switch Translation, Part 1 Maurizio Cimadamore and Brian Goetz December 2017 This document examines the current translation of `switch` constructs

Re: New JEP: Switch Expressions for the Java Language

Reading the original proposal. First, I think it's great. I think a lot of existing switches would look nicer as expression switches. ... and be less error-prone. I think most of my questions surround how these changes will (or /should/) affect non-expression switches. * Should we

Re: default branch placement in switch

On Fri, Nov 3, 2017 at 5:25 PM, Brian Goetz <brian.go...@oracle.com <mailto:brian.go...@oracle.com>> wrote: or plan to eventually get to a place where default always comes last, even for "int" switches. If we want to get to the latter, we should start warning

Re: New JEP: Switch Expressions for the Java Language

* Should we make it possible to use the new expression switch construct in non-expression contexts? Any values returned by a case would be ignored. Optionally we could skip requiring default to be present (meh). Users may want this because it's really nice to not have to

Re: New JEP: Switch Expressions for the Java Language

I think this sort of falls out for free; expressions are generally usable as statements, unless we can't determine their standalone type (like lambdas).  However, I'm not sure this would be good practice. I'm not sure either.  Ignoring the value of an expression is often a smell. BTW I

Switch translation, part 2

# Switch Translation, Part 2 -- type test patterns and guards Maurizio Cimadamore and Brian Goetz December 2017 This document examines possible translation of `switch` constructs involving `case` labels that include type-test patterns, potentially with guards.  Part 3 will address

Re: New JEP: Switch Expressions for the Java Language

tional expression — anything goes, locals can be mutated - can read locals, but can’t write them — a reasonable position, but unlike anything else so far - like lambdas - effectively final locals only. > On Dec 7, 2017, at 5:33 PM, Brian Goetz <brian.go...@oracle.com> wrote: > &

Switching on float/double/long

A target of opportunity for the new switch JEP is to fill out the set of types that traditional switches can operate on -- specifically float, double, and long.  The reason that we don't support these now is mostly an accident of history; the `tableswitch` and `lookupswitch` opcodes are

Re: New JEP: Switch Expressions for the Java Language

to summarize, we enhance le old switch by adding comma separated list of case values and by adding null as a possible pattern, and a warning if there is no default or the default is not at the ends, then we add an expression switch which extends the old switch as a poly expression with no

Fwd: Small things Java lets you do, but not everywhere.

Received via the spec-comments list. Not a comment on any specific extant project; instead, a wish-list, and mostly stuff we’ve seen before — array literals, generic maps, union types. > Begin forwarded message: > > From: Jeremy Barrow > Subject: Small things Java lets you do, but not

Re: Patterns and nulls

to a simple decision about whether we want to distort nested total (type-restating) type patterns to be null-friendly or null-hostile. On 3/14/2018 12:58 PM, Brian Goetz wrote: In the message "More on patterns, generics, null, and primitives", Gavin outlines how these

Updated pattern match documents

I've updated the documents regarding pattern matching, and uploaded them here: http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html http://cr.openjdk.java.net/~briangoetz/amber/pattern-semantics.html The first document is an update of a previous document (old version available

Re: Updated pattern match documents

Seems that the new document steps away from dedicated matching operator like __matches which we saw before and reuses instanceof instead. Yes -- the __matches notation was always a placeholder for something, which might have been `instanceof` all along; we just weren't sure whether

Re: Updated pattern match documents

I think, this part requires clarification. Some interesting cases: switch(boolValue) {case true:case false:case _:break;} -- is case _ a compilation error? What if case _ is changed to default? switch(boxedBoolValue) {case true:case false:case null:case _:break;} -- the same question So,

Raw string literals -- restarting the discussion

As many of you saw, we pulled back the Raw String Literals feature from JDK 12. The public statement is here: http://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002402.html So, let's restart the design discussion. First, I want to enumerate some of the process errors I think we

break-with

> Being able to call this something like `break-with v` (or some other derived > keyword) would have made this all a lot simpler. (BTW, we can still do this, > since expression-switch is still in preview.) It seems we’re all in favor of break-with over unadorned “break”? Which feeds into the

Re: nest syntax proposal

This is a nice example of “today’s problems come from yesterday’s solutions.” In Java 1.1, we did nested classes, and they were pretty cool, but there were some mismatches between the language model and the runtime model, which had some sharp edges. So, as a solution to that problem, we

Re: nest syntax proposal

ote: > > - Mail original - >> De: "Brian Goetz" >> À: "Remi Forax" >> Cc: "amber-spec-experts" >> Envoyé: Dimanche 20 Janvier 2019 18:04:00 >> Objet: Re: nest syntax proposal > >> This is a nice example of “today’s pr

Re: nest syntax proposal

> And they understand auxiliary classes. Let’s work with the familiar > concepts. > > but your solution seems tailored to sealed types, what if i have several > record classes with no common abstract type, how it works ? > and again there is no refactoring between a classical interface and

Re: Multiple return values

a call to map(), a type as to be provided, by example aStream.map(x -> (x, x + 1)).collect(...) Rémi - Mail original - De: "Brian Goetz" À: "Lukas Eder" Cc: "amber-spec-comments" Envoyé: Vendredi 11 Janvier 2019 17:07:43 Objet: Re: Multiple return values While

Re: enhanced enums - back from the dead?

> Secondly, it's hard to imagine there being any unforeseen consequences of > switching on a long. Here, I don't really know how to think it through yet. I > would appreciate any "here's how we know that the changes we need to support > this will have no user-visible consequences at all

Re: enhanced enums - back from the dead?

> Thanks to your explanation I see that this case is like that one in theory. > It's not quite the same thing in practice. That is, I know that a person can > both read and write "switch (someLong)" with no puzzlement, but I don't think > the same is true here; enumness and genericness are

Re: enhanced enums - back from the dead?

In this feature, there are two changes (that we know of so far) that might cause such observable effects. 1.  Not erasing the type parameter of Enum when computing the super type of a raw enum type. 2.  Changing the translation of enum constants.  Right now, if you have an enum constant

Re: enhanced enums - back from the dead?

> If we restrict this only to enums, of course this would be a non-issue; as > you say, enums are non-generic right now, so we have a clean slate (assuming > we're ok with the asymmetry). > There’s an even more conservative option: restrict this only to the type variable of Enum>, not just

Re: enhanced enums - back from the dead?

Thanks for the data! Can you clarify: is 1 out of 55Kfiles for the "all raw type refs" option, or the "only for raw enum refs"?  It looks like you are saying the former? On 12/10/2018 4:27 PM, Liam Miller-Cushon wrote: I did some corpus analysis for the following question from your doc:

Flow scoping

(Note to observers: we did an internal survey so I could gauge the comfort level of the EG with the flow scoping rules for pattern binding variables.  We'll do a public survey at some point in the future.) Thanks for taking the time to take the quiz.  The results were pretty good.  For the

Re: enhanced enums - back from the dead?

This uber-conservative approach seems a pretty reasonable approach to me; after all, enums are a language feature, and Enum is a constrained class (can't implement it directly), so it is not unreasonable to define its typing wrt its supertypes specially. So, let's get back to Maurizio's

Fwd: Re: enhanced enums - back from the dead?

Received on the -comments list. Forwarded Message Subject:Re: enhanced enums - back from the dead? Date: Tue, 11 Dec 2018 11:13:52 + From: elias vasylenko To: amber-spec-comme...@openjdk.java.net So going back a little, the suggestion of Rémi is to have

Re: Sealed types

Is the intention to allow this: module M; package x.y.z; __Sealed interface I { } class A implements I {} __Unsealed interface B extends I {} Then, in another compilation unit: module N; package a.b.c; class C implements B {} Yes, unsealing removes all subclassing restrictions. ... and

Re: Sealed types

|sealed interface Node { ... } | In this streamlined form, |Node| may be extended only by its nestmates. This may be suitable for many situations, but not for all; in this case, the user may specify an explicit |permits| list: |sealed interface Node permits FooNode,

Re: Sealed types

> > Note: It is probably desirable to ship this with records, though it could be > shipped before or after. > Interesting: I would have expected you to say exactly that but for > pattern-matching instead of records. All these features work nicely together, but the kinship I was thinking of

Re: Sealed types

I’ve updated the document on sealing to reflect the discussion so far. Sealed Classes *Definition.* A /sealed type/ is one for which subclassing is restricted according to guidance specified with the type’s declaration; finality can be considered a degenerate form of sealing, where no

Re: Sealed types

se at all.  Overall its probably still a good tradeoff, but we do have to paint this shed acceptably.) On 12/7/2018 11:38 AM, Brian Goetz wrote: I’ve updated the document on sealing to reflect the discussion so far. Sealed Classes *Definition.* A /sealed type/ is one for

Re: Sealed types

Maybe "permits" -> "exclusivelyIncludes" or just "exclusively"? These seem less likely to be misinterpreted and also less likely to lead to any confusion with not-rare use of "permits" as a variable (in semaphores etc). Good thought. Is there any reason except convenience to use the implicit

Re: Sealed types

You are right, either way would be justified. I get why you like it this way; that’s a valid opinion. But, be careful of the “just add a switch to make it go the other way” argument; while that certainly seems like it might “make everyone happy” in that everyone can express what they want,

Re: Sealed types

- it works for anonymous class declared in the same compilation unit ? Anonymous classes are a good question.  On the one hand, I can imagine when they might be useful.  On the other, it means there's no way anyone -- including the current class, to which all the

Re: Lifting the restriction on the number of public classes per file

in Bourrillion wrote: Sorry for delay. Can we unpack the "for whatever reason" part?  For what reason? Unsurprisingly to anyone, we actually hard-ban this practice here. Multiple top-level classes per file just make code harder to find; what are the advantages? On Mon, Nov 1

Re: Lifting the restriction on the number of public classes per file

Will imports always be necessary when pattern matching on sealed types, or could there be something like the provision for enum switches? We could expose a model where a sealed nest is more like an enum, and the nest members are more like enum constants, in which case using the same rules

Sealed types

Since we’re already discussing one of the consequences of sealed types, let’s put the whole story on the table. These are my current thoughts, but there’s room in the design space to wander a bit. *Definition.* A /sealed type/ is one for which subclassing is restricted according to guidance

Re: Can switch expression be compile-time constant?

Yes, this was a deliberate choice. Sent from my iPad > On Nov 22, 2018, at 5:18 AM, Tagir Valeev wrote: > > Hello! > > It seems that switch expressions are not compiled as compile-time > constant (using Java12 ea builds). E.g.: > > public class Constant { > public static void

Re: Sealed types

Or, if not additive, but we end up reusing the `final` keyword in the way shown at the bottom of this email, then we could at least allow `permits //, TypeA, TypeB` which is maybe nearly as good. In light of this morning's observation about hyphenated keywords ... there's a lot in this

Re: Flow scoping

Essentially, you're saying that if someone declares a pattern variable that would shadow a DU (final, please!) local, then the variables are merged and the scope is pinned at the scope of the local.  That's nice in that the scope and declaration point are now clearer, but on the other hand the

Re: Enhancing Java String Literals Round 2

> \""•multiline, no escapes, cannot contain the nonce followed by two > double quotes•"" > > where ‘•’ represents a nonce string (the same string at each end), which has > to be one of the following: This is an interesting middle ground. Off the top of my head, I would think we’d

We need more keywords, captain!

This document proposes a possible move that will buy us some breathing room in the perpetual problem where the keyword-management tail wags the programming-model dog. ## We need more keywords, captain! Java has a fixed set of _keywords_ (JLS 3.9) which are not allowed to be used as

Fwd: Hyphenated keywords and switch expressions

Received from the -comments list. > Begin forwarded message: > > From: Ben Evans > Subject: Hyphenated keywords and switch expressions > Date: January 11, 2019 at 5:19:25 AM EST > To: amber-spec-comme...@openjdk.java.net > > Hi EG members, > > I had a couple of comments on hyphenated

Re: Multiple return values

While I understand where you’re coming from, I think multiple return is likely to be both more intrusive and less satisfying than it first appears. First, it’s a relatively deep cut; it goes all the way down to method descriptors, since methods in the JVM can only return a single thing. So

Fwd: Multiple return values

Received on the comments list. > Begin forwarded message: > > From: Lukas Eder > Subject: Multiple return values > Date: January 11, 2019 at 10:57:19 AM EST > To: amber-spec-comme...@openjdk.java.net > > Hello, > > I'm referring to the exciting proposed new features around destructuring >

Fwd: Raw string literals: learning from Swift

Received on the -comments list. > Begin forwarded message: > > From: Fred Curts > Subject: Raw string literals: learning from Swift > Date: January 11, 2019 at 2:15:10 PM EST > To: amber-spec-comme...@openjdk.java.net > > With Swift 5 recently adding custom String delimiters (also called raw

Sealed types -- updated proposal

|Here's an update on the sealed type proposal based on recent discussions. | *Definition.* A /sealed type/ is one for which subclassing is restricted according to guidance specified with the type’s declaration; finality can be considered a degenerate form of sealing, where no subclasses at

Re: Sealed types

> > We can introduce them as sealed interface (note: interface not type) This is a new claim. Why is it that abstract classes can’t be sealed as well? (There is less _need_ for this, as abstract classes can use access control on their constructors to simulate sealing, but that’s a weak

Re: nest syntax proposal

t; a record or vice-versa will create instant puzzler. > We can only support sealed interface, not sealed class, it may be not a bad > idea per itself, anyway i think we should no try to mix nesting and subtyping. > > Rémi > > De: "Brian Goetz" > À: "Remi Forax" &

Re: [sealed] Changes to type system

Don't we have a similar problem with non-accessible supertypes and inference?  If I have:     private abstract class A { }     public class B extends A { }     public class C extends A { } Won't I infer LUB(B,C) = A, rather than Object? On 2/25/2020 6:08 AM, Maurizio Cimadamore wrote: But

Re: Pattern Matching for instanceof (Preview 2)

Conveniently, an inferred type pattern _is_ an any pattern.  (See the explanation in the recent discussion on nullity, where this fell out nicely.)   So semantically a var pattern is an any pattern. not if there are multiple de-constructors with the same arity, right ? It still is an _any_

Re: Pattern Matching for instanceof (Preview 2)

var is not really any, it's an inferred type pattern. '_' is any, no ? Conveniently, an inferred type pattern _is_ an any pattern.  (See the explanation in the recent discussion on nullity, where this fell out nicely.)   So semantically a var pattern is an any pattern. Whether or not we

Re: Pattern Matching for instanceof (Preview 2)

I see two questions: - the grammar allows to mix var and non-var for a given reference type, i think that should only permitted if the non var is a deconstruction itself ? More generally, any pattern can appear nested inside a deconstruction pattern -- another deconstruction pattern, a var

Re: IntelliJ IDEA 2020.1 EAP with Records/Patterns support

Great news, Tagir.  It is super to see strong early IDE support -- that means we will are more likely to get useful feedback when we can still act on it! On 1/24/2020 10:33 PM, Tagir Valeev wrote: Hello! I'm happy to announce that JetBrains started an Early Access Program for IntelliJ IDEA

Re: Pattern Matching for instanceof (Preview 2)

I don’t know what you mean here. There are two patterns, a type test pattern and a deconstruction pattern. In v2 we propose to support deconstruction patterns over record types *only*. A deconstruction pattern looks like this: Point(var a, var b), i.e. all the components are either

[records] Record updates for Preview/2

We're gathering a list of what non-bugfix things we want to do for the second preview of records.  So far, on my list, I have: 1.  Revisiting the j.l.Record supertype.  We want to support inline records when we have inline types.  Until now, we've been working on the assumption in Valhalla

Re: [records] updates for Preview 9. hashCode

No objection to further hashing the specification of the hash.  Care to post a proposed patch for the spec in j.l.Record? On 1/9/2020 11:45 PM, John Rose wrote: If we don’t decide hashCode explicitly, I think we’ll back ourselves into a bad default decision. Should the hashing logic for

Re: Towards cleaner nesting

- interfaces can't directly contain instance initializers/constructors, instance/local variables, or inner classes (maybe) In order to have inner classes in an interface, we'd have to have a non-static modifier, since nested classes in interfaces are allowed now and are implicitly static.

Re: Component deprecation

The Deprecated attribute is, effectively, Deprecated.  So I'm not interested in giving it any life support. I think there is a confusion somewhere. The JVMS has no word about deprecating the attribute Deprecated, javac 14 is using it, so i don't understand. For me, a record

Re: [patterns] Nullability in patterns, and pattern-aware constructs (again)

) { ... }     if (x instanceof "") { ... }     if (i instanceof 3) { ... } Or not -- I suspect not. On 1/8/2020 3:27 PM, Brian Goetz wrote: In the past, we've gone around a few times on nullability and pattern matching.  Back when we were enamored of `T?` types over in Valhalla land,

Re: Towards cleaner nesting

FWIW, I think it's helpful for case analysis to flatten the list of things that can be nested/contain nested things as follows: - top-level/static classes - inner classes* (I always forget whether this includes local classes, but turns out it does) - interfaces - records - enums -

Component deprecation (was: [records] Record updates for Preview/2)

not-interested in spending any spec or compiler effort on this, though.  Its an annotation; we support annotations. On 1/9/2020 12:51 PM, fo...@univ-mlv.fr wrote: *De: *"Brian Goetz" *À: *"Remi

Re: [records] updates for Preview 9. hashCode

This is almost OT but it's a question I was asked for twice, what is the rational to use the angle bracket instead of the parenthesis ? I surveyed a variety of implementations of toString(), and picked what seemed most common, which was some variant of:     Type[v=vVal, u=uVal] Which was

Re: [records] Specify use of @Override and @SafeVarargs on record components

Nice catch, Tagir.  Historically the @Target meta-anno has been strong enough to keep people from putting annos in the wrong place, but with the "clever" handling of annos with records (accepting any of the target types an anno can be reasonably pushed down to), we don't have any way of saying

Re: More constraints on nesting that could be relaxed

Understood; restricting to methods only here was probably gratuitously bespoke.  I would indeed like to clean this up too (though, while it might sound like a "one line change to the compiler", it is actually way more work than it sounds, because it affects both JLS and JVMS, so requires code

Re: [patterns] Nullability in patterns, and pattern-aware constructs (again)

I'm just thinking if such arrangement allows expressing all possible situations that may arise in a switch. Imagine one wants to switch on (Object o) and have the following cases: - String: case 1 - CharSequence or null: case 2 - any other: case 3 How would one structure such switch? Would

Re: [records] Record updates for Preview/2

- @Deprecated on record components Please outline what you think we want on a separate thread? - change the bootstrap method protocol (a little bit) Let's start a thread on this too.   - equals/hashCode implementation are currently slow Can you qualify/quantify "slow"?   - the

Re: [patterns] Nullability in patterns, and pattern-aware constructs (again)

(total) and bottom (null constant) patterns match null.  Guy is happy again.  (And the crowd goes wild.) On 1/9/2020 10:53 PM, John Rose wrote: On Jan 9, 2020, at 7:04 PM, Brian Goetz wrote: I guess that means the stuff I said about "only having to look in two places" for nul

Re: [records] translation strategy (factory methods)

There is a whole category if "ooh, shiny new language construct, this is an opportunity to slide in some new features."  We saw this with lambdas -- "can you please make the parameters of lambdas implicitly final."  The motivation for such requests is obvious; we wish all parameters could be

Re: [records] updates for Preview 6. Default access modes

This is where we want to aim for.  It was not practical (for reasons of accidental-complexity management) in preview/1 but those issues have been addressed and it is now practical to get there. On 1/10/2020 5:04 AM, Tagir Valeev wrote: Of these options, I like C the most, though I would

Re: equals/hashCode/toString implementation

sure ! toString is very very very slow, equals can be a little bit faster, hashCode has no issue. toString is a known issue; we have a separate project to speed up String.format() across the board, so we didn't do anything special for toString here.  But I'm sure the bootstrap can be

Re: [records] translation strategy

A significant reason to have a supertype is not API points, but API specs.  We can refine the spec of equals() if there is an abstract Record type. On 1/10/2020 12:09 AM, John Rose wrote: A. Specify a super type now, and add the new API connection points to the super type. It could be an

Re: [records] New draft spec for JEP 359

I don't see any changes regarding the variable arity mismatch between the canonical constructor and record header. See my e-mail [1]. Was this suggestion rejected or overlooked? We might also want to just outlaw the old-style array declaration for components:     record Foo(int a[]) // error   

Re: [records] New draft spec for JEP 359

On 1/10/2020 11:30 AM, Tagir Valeev wrote: I don't see any changes regarding the variable arity mismatch between the canonical constructor and record header. See my e-mail [1]. Was this suggestion rejected or overlooked? This can be accomplished by adding  - If the record is a varargs

[patterns] Nullability in patterns, and pattern-aware constructs (again)

In the past, we've gone around a few times on nullability and pattern matching.  Back when we were enamored of `T?` types over in Valhalla land, we tentatively landed on using `T?` also for nullable type patterns.  But the bloom came off that rose pretty quickly, and Valhalla is moving away

  1   2   3   4   5   6   7   8   9   >