Hi all,
Let say we have a Point with 2 components
record Point(int x, int y) { }
Then we change the record to add a 3rd components in a more or less backward
compatible way
record Point(int x, int y, int z) {
Point(int x, int y) {
this(x, y, 0); // creation of the new value 0
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Friday, June 10, 2022 2:44:51 PM
> Subject: "With" for records
> In
> [
> https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md
> |
>
- Original Message -
> From: "Brian Goetz"
> To: "daniel smith" , "amber-spec-experts"
>
> Sent: Thursday, June 2, 2022 8:08:14 PM
> Subject: Re: Simplifying switch labels
>> In this framing, the restrictions about sets of elements in a single label
>> don't
>> apply, because we're
> From: "Brian Goetz"
> To: "Tagir Valeev"
> Cc: "amber-spec-experts"
> Sent: Tuesday, May 31, 2022 6:12:06 PM
> Subject: Re: Named record pattern
> Gavin reminded me that we are not finalizing patterns in switch in 19 (hard to
> keep track, sometimes), so we have a little bit of time to
> From: "Maurizio Cimadamore"
> To: "Brian Goetz" , "Tagir Valeev"
> Cc: "amber-spec-experts"
> Sent: Tuesday, May 31, 2022 7:41:21 PM
> Subject: Re: Named record pattern
> While merging is an issue (if supported), I think early in the design we
> settled
> on the principle that a binding
Hi all,
i think the recent discussions about the pattern matching are too much about
details of implementation and i fear we are losing the big picture, so let me
explain why i (we ?) want to add pattern matching to Java.
Java roots is OOP, encapsulation serves us well for the last 25+ years,
Not sure if it's an implementation bug (bad error message from the compiler) or
a spec bug,
hence this message to both amber-dev and amber-spec-experts.
If i try to compile this code with Java 19 (which currently still uses &&
instead of when for a guard)
interface reverse_polish_notation {
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Wednesday, May 18, 2022 9:18:01 PM
> Subject: Pattern matching: next steps after JEP 405
> JEP 405 has been proposed to target for 19. But, it has some loose ends that
> I'd
> like to refine before it eventually becomes a final feature.
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Wednesday, May 18, 2022 9:18:01 PM
> Subject: Pattern matching: next steps after JEP 405
> JEP 405 has been proposed to target for 19. But, it has some loose ends that
> I'd
> like to refine before it eventually becomes a final feature.
I've found a way to encode the null pattern if you have a record
record Foo(int x) { }
Foo foo = ...
return switch(foo) {
case Foo(int _) foo -> "i'm a foo not null here !";
case Foo fooButNull -> "i can be only null here !";
};
I wonder if allowing those two patterns, a record pattern and
This is something i think we have no discussed, with a record pattern, the
switch has to call the record accessors, and those can do side effects,
revealing the order of the calls to the accessors.
So by example, with a code like this
record Foo(Object o1, Object o2) {
public Object o2()
Hi all,
i maybe wrong but it seems that the spec consider null as a kind of case
instead of as a kind of pattern, which disables the refactoring that should be
possible with the introduction of the record pattern.
Let suppose i have a sealed type with only one implementation declared like this
> From: "Guy Steele"
> To: "Brian Goetz"
> Cc: "amber-spec-experts"
> Sent: Saturday, April 16, 2022 4:10:06 AM
> Subject: Re: Evolving past reference type patterns
> Yes, this is a clear improvement to the example code.
> That said, I am always (or at least now) a bit leery of language
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Friday, April 15, 2022 10:50:27 PM
> Subject: Evolving past reference type patterns
[...]
> There are also some small differences between the safe cast conversions and
> method invocation context. There is the same issue with unboxing
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Thursday, April 7, 2022 9:54:11 PM
> Subject: Re: Primitive type patterns
> There's another, probably stronger, reason why primitive patterns supporting
> widening, narrowing, boxing, unboxing, etc, are basically a forced move,
> besides
- Original Message -
> From: "Dan Heidinga"
> To: "Brian Goetz"
> Cc: "amber-spec-experts"
> Sent: Wednesday, March 30, 2022 8:43:42 PM
> Subject: Re: [External] : Re: Remainder in pattern matching
> On Wed, Mar 30, 2022 at 2:38 PM Brian Goetz wrote:
>>
[...]
>
> And from your
- Original Message -
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Wednesday, March 30, 2022 9:33:21 PM
> Subject: Patterns and GADTs (and type checking and inference and overload
> selection)
> GADTs -- sealed families whose permitted subtypes specialize the type
>
- Original Message -
> From: "Brian Goetz"
> To: "Dan Heidinga"
> Cc: "amber-spec-experts"
> Sent: Wednesday, March 30, 2022 8:26:53 PM
> Subject: Re: [External] : Re: Remainder in pattern matching
[...]
>
> One thing wrapping gains is that it gives us a place to centralize
>
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Wednesday, March 30, 2022 4:40:28 PM
> Subject: Remainder in pattern matching
> We should have wrapped this up a while ago, so I apologize for the late
> notice,
> but we really have to wrap up exceptions thrown from pattern contexts
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Tuesday, March 29, 2022 11:01:18 PM
> Subject: Declared patterns -- translation and reflection
> Time to take a peek ahead at _declared patterns_. Declared patterns come in
> three varieties -- deconstruction patterns, static patterns,
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Tuesday, March 29, 2022 11:01:18 PM
> Subject: Declared patterns -- translation and reflection
> Time to take a peek ahead at _declared patterns_. Declared patterns come in
> three varieties -- deconstruction patterns, static patterns,
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Tuesday, March 29, 2022 11:01:18 PM
> Subject: Declared patterns -- translation and reflection
> Time to take a peek ahead at _declared patterns_. Declared patterns come in
> three varieties -- deconstruction patterns, static patterns,
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Friday, March 25, 2022 4:38:52 PM
> Subject: Pattern assignment
> We still have a lot of work to do on the current round of pattern matching
> (record patterns), but let's take a quick peek down the road. Pattern
> assignment is a
Thanks for sharing,
in the text, they are several mentions of the default pattern but the default
pattern is not defined.
Rémi
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Thursday, March 24, 2022 6:39:21 PM
> Subject: Pattern coverage
> I've put a document at
> [
Hi all,
while writing the prototype of the runtime,
i found a case i think we never discuss, can we match an empty record ?
record Empty() { }
switch(object) {
case Empty() -> ... // no binding here
I think the answer is yes because i don't see why we should do a special case
for that, but
Following the discussions we had, i've implemented a prototype of what can be
the runtime part of the pattern matching that supports record pattern.
It works in 3 steps:
Step 1, at compile time, the compiler takes all the patterns and creates a tree
of pattern from the list of patterns,
pattern
> From: "Remi Forax"
> To: "Brian Goetz"
> Cc: "Jim Laskey" , "amber-spec-experts"
>
> Sent: Saturday, March 5, 2022 11:54:14 PM
> Subject: Re: [External] : Re: Proposal: java.lang.runtime.Carrier
>> From: "Brian G
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Thursday, March 3, 2022 9:42:25 PM
> Subject: Telling the totality story
> Given the misconceptions about totality and whether "pattern matching means
> the
> same thing in all contexts", it is pretty clear that the story we're telling
For the pattern matching,
we also need a 'with' method, that return a method handle that takes a carrier
and a value and return a new carrier with the component value updated.
static MethodHandle withComponent(MethodType methodType, int i)
// returns a mh (Carrier;T) -> Carrier with T the
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Monday, February 28, 2022 5:50:25 PM
> Subject: Re: Primitive type patterns
> Let me put the central question here in the spotlight.
>> Boxing and unboxing
>> Suppose our match target is a box type, such as:
>> record
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Friday, February 25, 2022 10:45:44 PM
> Subject: Primitive type patterns
> As a consequence of doing record patterns, we also grapple with primitive type
> patterns. Until now, we've only supported reference type patterns, which are
>
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Wednesday, February 16, 2022 7:34:17 PM
> Subject: Record patterns (and beyond): exceptions
> As we move towards the next deliverable -- record patterns -- we have two new
> questions regarding exceptions to answer.
> Questions
>
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Wednesday, February 16, 2022 4:49:19 PM
> Subject: Re: Reviewing feedback on patterns in switch
> One thing that we have, perhaps surprisingly, *not* gotten feedback on is
> forcing all non-legacy switches (legacy type, legacy labels,
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Tuesday, February 15, 2022 7:50:06 PM
> Subject: Re: Reviewing feedback on patterns in switch
> We're preparing a third preview of type patterns in switch. Normally we would
> release after a second preview, but (a) we're about to get
Hi Gavin,
I don't buy the argument that record patterns promote a null-safe style of
programming as this is stated several times in the JEP.
The ""null-safety"" (notice the air quotes) mostly comes from the instanceof or
the switch (which semantics is equivalent of a cascade of if instanceof),
> From: "Brian Goetz"
> To: "Tagir Valeev" , "amber-spec-experts"
>
> Sent: Thursday, February 3, 2022 5:35:13 PM
> Subject: Re: Control flow analysis for exhaustive pattern-switch statement
> Thanks Tagir for digging into this. This is good analysis.
> The decision to require completeness of
- Original Message -
> From: "mark"
> To: "Brian Goetz"
> Cc: "amber-spec-experts"
> Sent: Friday, January 28, 2022 12:43:55 PM
> Subject: Re: Reviewing feedback on patterns in switch
> On 2022-01-25T19:46:09 +
> Brian Goetz wrote:
>
>> We’ve previewed patterns in switch for two
Here are several examples showing that the inference does work as expected from
a beginner POV,
the first two examples come from one of my student.
Here, list is typed as List instead of List
var value = ...
var list = switch (value) {
case 0 -> List.of();
case 1 -> List.of("foo");
- Original Message -
> From: "Tagir Valeev"
> To: "Brian Goetz"
> Cc: "amber-spec-experts"
> Sent: Wednesday, January 26, 2022 4:50:05 AM
> Subject: Re: Positioning of guards (was: Reviewing feedback on patterns in
> switch)
> Hello!
>
> For the record: I like the current version
- Original Message -
> From: "Tagir Valeev"
> To: "Brian Goetz"
> Cc: "amber-spec-experts"
> Sent: Wednesday, January 26, 2022 5:20:24 AM
> Subject: Re: Treatment of total patterns (was: Reviewing feedback on patterns
> in switch)
>> Null is only matched by a switch case that includes
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Tuesday, January 25, 2022 8:47:09 PM
> Subject: Treatment of total patterns (was: Reviewing feedback on patterns in
> switch)
>> 1. Treatment of total patterns in switch / instanceof
> The handling of totality has been a long and painful
- Original Message -
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Tuesday, January 25, 2022 8:49:02 PM
> Subject: Positioning of guards (was: Reviewing feedback on patterns in switch)
>> 2. Positioning of guards
>
> We received several forms of feedback over the form and
- Original Message -
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Tuesday, January 25, 2022 8:49:08 PM
> Subject: Patterns and GADTs (was: Reviewing feedback on patterns in switch)
>> 3. Type refinements for GADTs
>
> There are a number of unsatisfying aspects to how we
- Original Message -
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Tuesday, January 25, 2022 8:49:12 PM
> Subject: Diamond in type patterns (was: Reviewing feedback on patterns in
> switch)
>> 4. Diamond for type patterns (and record patterns)
>
>
> The type pattern `T t`
Moved to amber-spec-experts,
I've got a very similar issue, if we support patter matching on Class.
public Stream createPrimitiveStrem(Class type) {
return switch(type) {
case int.class -> new SpecializedStream();
case double.class -> new SpecializedStream();
...
};
> From: "Brian Goetz"
> To: "John Rose"
> Cc: "amber-spec-experts"
> Sent: Mardi 2 Novembre 2021 18:43:29
> Subject: Translation musings (was: Are templated string embedded expressions
> "method parameters" or "lambdas"?)
> I think we need to redirect a bit.
>> I’m pointing out a different
> From: "John Rose"
> To: "Guy Steele"
> Cc: "Brian Goetz" , "Tagir Valeev"
> ,
> "Jim Laskey" , "amber-spec-experts"
>
> Sent: Dimanche 31 Octobre 2021 01:18:38
> Subject: Re: Are templated string embedded expressions "method parameters" or
> "lambdas"?
> On Oct 30, 2021, at 3:22 PM, John
Happy Halloween,
i spend some time again thinking how to implement templated strings.
>From the comments of my previous attempt, the main issues of the previous
>iteration were that it was a little too magical and by using a bootstrap
>method force the BSM design into the JLS.
So i try to
> From: "Jim Laskey"
> To: "amber-spec-experts"
> Sent: Vendredi 29 Octobre 2021 16:10:54
> Subject: Are templated string embedded expressions "method parameters" or
> "lambdas"?
> For our early templated string prototypes , we restricted embedded expressions
> to just basic accessors and basic
I've recently proposed another way to implement the templated string/template
policies but i may not have made it clear why i think the current proposal [1]
is bad.
First, some vocabulary, a templated string is a string with some unnamed
parameters that are filled with the result of
Hi everybody, i've spend some time to think how the String interpolation +
Policy should be specified and implemented.
The goal is to add a syntax specifying a user defined method to "interpolate"
(for a lack of better word) a string with arguments.
Given that it's a method, the exact
> From: "Kevin Bourrillion"
> To: "Maurizio Cimadamore"
> Cc: "Brian Goetz" , "amber-spec-experts"
>
> Sent: Jeudi 7 Octobre 2021 22:37:58
> Subject: Re: Minor improvement to anonymous classes
> On Thu, Oct 7, 2021 at 7:37 AM Maurizio Cimadamore < [
> mailto:maurizio.cimadam...@oracle.com |
> From: "Gavin Bierman"
> To: "Brian Goetz"
> Cc: "amber-spec-experts"
> Sent: Vendredi 1 Octobre 2021 14:49:01
> Subject: Re: Pattern Matching for switch (Second Preview)
>> On 30 Sep 2021, at 23:25, Brian Goetz < [ mailto:brian.go...@oracle.com |
>> brian.go...@oracle.com ] > wrote:
>> [
> From: "Brian Goetz"
> To: "Gavin Bierman"
> Cc: "amber-spec-experts"
> Sent: Vendredi 1 Octobre 2021 00:25:26
> Subject: Re: Pattern Matching for switch (Second Preview)
> [ moving to a-s-e ]
> I get the concern that a type pattern is no longer "just a variable
> declaration"; that was a
There is a bad interaction between a lambda and a switch expression,
a lambda allows its expression to be typed void but a switch expression can not
be typed void,
so the following code does not compile
sealed interface I permits A, B {}
record A() {}
record B() {}
public Optional
[re-sent to amber-spec-experts instead of amber-dev]
- Original Message -
> From: "Brian Goetz"
> To: "Vikram Bakshi" , "amber-dev"
>
> Sent: Samedi 25 Septembre 2021 17:28:11
> Subject: Re: Feedback on pattern matching (preview feature)
> The example you cite is a peek into a feature
- Original Message -
> From: "Zheka Kozlov"
> To: "amber-dev"
> Sent: Vendredi 24 Septembre 2021 10:30:54
> Subject: Sealed Exception
> Hi!
CC amber-spec-experts
>
> Java 17 compiler forces me to insert an unreachable catch block for the
> base Exception:
>
> public static void
- Original Message -
> From: "Tagir Valeev"
> To: "Jim Laskey"
> Cc: "amber-spec-experts"
> Sent: Vendredi 17 Septembre 2021 12:49:30
> Subject: Re: String Tapas Redux: Beyond mere string interpolation
> It's interesting that in both Scala and JavaScript when you define
> custom
- Original Message -
> From: "John Rose"
> To: "Jim Laskey"
> Cc: "amber-spec-experts"
> Sent: Vendredi 17 Septembre 2021 08:43:29
> Subject: Re: String Tapas Redux: Beyond mere string interpolation
> Yay!
>
> I agree with Brian’s response to Remi: Nothing new here
> regarding eval
Brian explicitly ask me to not talk about invokedynamic so i will not say that
there is already an existing protocol between invokedynamic and a user defined
implementation, it's the bootstrap method,
Let's talk about the elephant in the room: macro.
Templated Strings as currently defined is
- Original Message -
> From: "Brian Goetz"
> To: "daniel smith" , "Dan Heidinga"
>
> Cc: "valhalla-spec-experts"
> Sent: Vendredi 10 Septembre 2021 20:25:50
> Subject: Re: Factory methods & the language model
>> I'm not particularly interested in settling on a bikeshed color, but am
Hi all,
the current spec support merging/fallthrough cases only when there is a case
null,
like
case null, case Integer i -> // i can use 'i' here
First, i'm not sure it's clearly written in the spec, i was not able to
pinpoint the rule allowing it.
Then i wonder if this special behavior is
- Original Message -
> From: "Brian Goetz"
> To: "Tagir Valeev" , "amber-spec-experts"
>
> Sent: Lundi 6 Septembre 2021 15:46:19
> Subject: Re: Reiterate total pattern accepting null in switch
> On 9/6/2021 5:12 AM, Tagir Valeev wrote:
>> Hello!
>>
>> Now, as we develop support in
Another case where the spec is weird,
i've converted a project that generate a visitor from a grammar (something like
yacc) to use a switch on type instead.
Sometimes for a degenerate portion of the grammar i've an empty visitor that
always throw an exception,
the equivalent code with a switch
Here is another example with i believe the same issue
sealed interface Vehicle {}
record Car(String owner, String color) implements Vehicle {}
record Bus(String owner) implements Vehicle {}
public static void example2() {
var vehicles = List.of(
new Car("Bob", "red"),
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Vendredi 30 Juillet 2021 16:52:23
> Subject: Minor improvement to anonymous classes
> I have been working on a library where I've found myself repeatedly
> refactoring
> what should be anonymous classes into named (often local) classes,
- Original Message -
> From: "Tagir Valeev"
> To: "Brian Goetz"
> Cc: "amber-spec-experts"
> Sent: Samedi 31 Juillet 2021 05:55:47
> Subject: Re: Minor improvement to anonymous classes
> By the way, assuming that we implement this, new IFace() {...} would
> be technically equivalent to
> From: "John Rose"
> To: "Tagir Valeev"
> Cc: "Brian Goetz" , "amber-spec-experts"
>
> Sent: Samedi 31 Juillet 2021 20:00:20
> Subject: Re: Minor improvement to anonymous classes
> On Jul 30, 2021, at 8:55 PM, Tagir Valeev < [ mailto:amae...@gmail.com |
> amae...@gmail.com ] > wrote:
>> 2.
- Original Message -
> From: "John Rose"
> To: "Brian Goetz"
> Cc: "amber-spec-experts"
> Sent: Samedi 31 Juillet 2021 00:14:46
> Subject: Re: Minor improvement to anonymous classes
> It seems reasonable: If you can do this for lambdas,
> which are (sort of) a concise anonymous inner
- Original Message -
> From: "daniel smith"
> To: "amber-spec-experts"
> Cc: "Gavin Bierman"
> Sent: Samedi 24 Juillet 2021 00:28:08
> Subject: Switch coverage with multiple branches
> An RFE for JEP 406 (or maybe bug fix? I haven't dug into what the spec says).
> Can we make this
> From: "Brian Goetz"
> To: "Gavin Bierman" , "Manoj Palat"
>
> Cc: "amber-spec-experts"
> Sent: Lundi 19 Juillet 2021 15:00:16
> Subject: Re: case null and type pattern
> Right. In theory, we could allow guarded patterns here, but they will be hard
> to
> use, since users will likely want to
- Original Message -
> From: "Manoj Palat"
> To: "amber-spec-experts"
> Sent: Jeudi 15 Juillet 2021 00:43:40
> Subject: case null and type pattern
> Hi Gavin, All,
HI Manoj,
>
> In
>
I was re-reading JEP 405,
'var foo' is accepted by the grammar as Type Pattern but
there is no section explicitly mentioning that.
Maybe i'm wrong and 'var foo' is already supported in Java 17,
if it's not the case, i think we should add a section about the Type Pattern
being enhanced to support
> De: "John Rose"
> À: "Maurizio Cimadamore"
> Cc: "daniel smith" , "amber-spec-experts"
>
> Envoyé: Mardi 22 Juin 2021 02:31:13
> Objet: Re: Experience with sealed classes & the "same package" rule
> That argument does not make sealing
> less useful or more dangerous in a
> non-modular
> De: "John Rose"
> À: "daniel smith"
> Cc: "amber-spec-experts"
> Envoyé: Jeudi 10 Juin 2021 00:29:40
> Objet: Re: Experience with sealed classes & the "same package" rule
> (Also on the same hit-list: The restriction against
> using local sealed hierarchies. The restriction
> doesn’t make any
- Mail original -
> De: "daniel smith"
> À: "amber-spec-experts"
> Envoyé: Mercredi 9 Juin 2021 23:42:16
> Objet: Experience with sealed classes & the "same package" rule
> Here's some late feedback on the sealed classes preview. Probably actionable
> before 17 GA, if that's what people
Hi all,
the first part of the message is about javac error message that could be
improved,
the second part is about the current spec being not very logical.
With this code
Object o = null;
var value = switch(o) {
//case null -> 0;
case Object __ -> 0;
case
Do we agree that the code below defines an exhaustive switch so no default is
necessary ?
sealed interface List permits Cons, Nil { }
record Cons(String value, Object next) implements List { }
enum Nil implements List { NIL }
int size(List list) {
return switch(list) {
case Cons cons -> 1
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Mercredi 19 Mai 2021 13:12:43
> Objet: Re: Rehabilitating switch -- a scorecard
> So, here's another aspect of switches rehabilitation, this time in terms of
> syntactic rewrites. By way of analogy with lambdas, there's a sequence of
> x
- Mail original -
> De: "Brian Goetz"
> À: "John Rose"
> Cc: "amber-spec-experts"
> Envoyé: Mardi 18 Mai 2021 04:37:55
> Objet: Re: Rehabilitating switch -- a scorecard
>> There are a few roads not taken: “switch ()” with boolean
>> case expressions has not showed itself worthy yet.
>
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Lundi 17 Mai 2021 23:36:30
> Objet: Rehabilitating switch -- a scorecard
> This is a good time to look at the progress we've made with switch. When we
> started looking at extending switch to support pattern matching (four years
> ago!) we
> De: "Maurizio Cimadamore"
> À: "Brian Goetz" , "amber-spec-experts"
>
> Envoyé: Mardi 27 Avril 2021 16:23:20
> Objet: Re: Switch labels (null again), some tweaking
> On 23/04/2021 16:38, Brian Goetz wrote:
>> So, I think the "a switch only accepts null if the letters n-u-l-l are
>>
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Mardi 27 Avril 2021 19:11:18
> Objet: Make all switches exhaustive?
> Maurizio's comment got me thinking about a possible way to eliminate the sharp
> edge of "sometimes switches are type-checked for exhaustiveness, and sometimes
> not."
I just want to add that there is another possible semantics than having case
null + total pattern as null acceptable pattern.
We have based the semantics of pattern matching to the semantics of the cascade
of if instanceof with an else at the end.
There is another one, method calls [1], a
- Mail original -
> De: "John Rose"
> À: "Brian Goetz"
> Cc: "amber-spec-experts"
> Envoyé: Vendredi 23 Avril 2021 21:27:40
> Objet: Re: Switch labels (null again), some tweaking
> On Apr 23, 2021, at 8:38 AM, Brian Goetz wrote:
>>
>> ...The fact is that the natural interpretation of
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Jeudi 1 Avril 2021 15:23:28
> Objet: Possible refinement for sealed classes
> Been working with sealed classes a lot lately, and have run into a pattern
> that
> we might want to consider supporting more directly, which is interfaces that
> De: "Gavin Bierman"
> À: "amber-spec-experts"
> Envoyé: Lundi 22 Mars 2021 13:03:31
> Objet: Draft JEP: Sealed Classes
> Dear all,
> Now JDK 16 is out (yay!) it’s time for us to focus on finalizing Sealed
> Classes
> in JDK 17.
> I have written a draft JEP, which is unchanged (other than
Hi, currently when there is an instanceof + type pattern with a raw type,
javec doesn't raise any warning (oops), worst it compiles because i believe it
should not, but for that, the spec has to be amended.
interface Foo {
void set(T t);
}
class FooImpl implements Foo {
private
De: "Brian Goetz"
À: "Remi Forax"
Cc: "amber-spec-experts"
Envoyé: Samedi 13 Mars 2021 02:41:58
Objet: Re: [External] : Re: Looking ahead: pattern assignment
BQ_BEGIN
BQ_BEGIN
BQ_BEGIN
Minimally, we have to align the semantics of local variabl
> De: "Alan Malloy"
> À: "Brian Goetz"
> Cc: "amber-spec-experts"
> Envoyé: Vendredi 12 Mars 2021 22:58:44
> Objet: Re: Looking ahead: pattern assignment
> try-with-resources is a little more subtle than the other contexts. Suppose
> that
> I write:
> try (Foo(Bar x) = ...) {
> ...
> }
>
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Vendredi 12 Mars 2021 20:58:40
> Objet: Looking ahead: pattern assignment
> While this is not on the immediate horizon, I think we are ready to put the
> pieces together for pattern assignment. I think we now understand the form
> this
>
- Mail original -
> De: "Gavin Bierman"
> À: "John Rose"
> Cc: "amber-spec-experts"
> Envoyé: Vendredi 12 Mars 2021 11:11:46
> Objet: Re: Guards redux
> Thanks everyone for the discussion. I have updated the JEP:
>
> http://openjdk.java.net/jeps/8213076
>
> It proposes *guarded
> De: "Brian Goetz"
> À: "Gavin Bierman" , "amber-spec-experts"
>
> Envoyé: Mercredi 10 Mars 2021 16:02:10
> Objet: Re: Guards redux
> This feels like we landed in a good place. It preserves the underlying goal of
> the original approach -- that we can compose patterns with patterns, and
>
- Mail original -
> De: "Gavin Bierman"
> À: "amber-spec-experts"
> Envoyé: Mercredi 10 Mars 2021 15:47:30
> Objet: Guards redux
> Okay, so it seems like our initial stab at guards and a pattern conjunction
> operator needs some finessing.
>
> Here's another take, inspired by Guy's
Apart from what have said about letting grobble to fully access to the
bindings,
i think that using parenthesis to call grobble here is already too much.
case Foo(var x) when x > y
is far more readable than
case Foo(var x) when (x > y)
because for a pattern the parenthesis describes a
- Mail original -
> De: "Gavin Bierman"
> À: "amber-spec-experts"
> Envoyé: Jeudi 18 Février 2021 13:33:20
> Objet: Two new draft pattern matching JEPs
> Dear all,
>
[...]
>
> - Pattern Matching for switch:
> https://bugs.openjdk.java.net/browse/JDK-8213076
>
> We split them up to
- Mail original -
> De: "Brian Goetz"
> À: "Tagir Valeev"
> Cc: "amber-spec-experts"
> Envoyé: Mardi 2 Mars 2021 18:44:27
> Objet: Re: [External] : Pattern assignment statements (extracted from:
> Primitive type patterns and conversions)
>> A couple of other things to consider:
>> 1.
- Mail original -
> De: "Gavin Bierman"
> À: "amber-spec-experts"
> Envoyé: Jeudi 18 Février 2021 13:33:20
> Objet: Two new draft pattern matching JEPs
> Dear all,
>
> The next steps in adding pattern matching to Java are coming! I have drafted
> two
> new JEPs:
I'm slowly trying to
[sent to both email list given it's not clear if it's an implementation issue
or a spec issue]
There is a nice video of how the serialization of records works recently on
inside.java
https://inside.java/2021/02/23/records-met-serialization/
In the video, Julia explains that the
Hi all,
in the news, Python have been accepted the PEP 642, Pattern Matching in Python
[1].
The accepted PEP is https://www.python.org/dev/peps/pep-0642/
And the rational is https://www.python.org/dev/peps/pep-0635/
Compared to us,
- bindings are visually like variables not a special keyword (a
1 - 100 of 352 matches
Mail list logo
