amber mailing lists traffic control

Hi, one further organizational announcement - as amber is composed by several branches, I suggest that, when sending an email _to any of the amber lists_ to discuss a given topic (regardless of whether the email is related to the code or not), the branch name is used as an header for the email

Re: Pattern Matching

Hi Andrey On 27/03/17 12:04, Andrey Breslav wrote: 3. And to share a little bit about smart casts (I'm flattered that you are using our terminology here ;) ): as soon as you have smart casts, the urge to get intersection types into the language strengthens, because of cases like this: if (x

Re: Pattern Matching

On 27/03/17 16:06, Andrey Breslav wrote: - I can check for (a != null) and then somewhere inside check for (a is MyClass). This does not directly apply to Java (unless we envision introduction of nullable types in the future). - In a mixed hierarchy, it may often makes sense to first check for

[enhanced enums] - end of the road?

Hi, over the last few weeks we've been carrying out experiments to test the feasibility of the enhanced enums feature. As described in the JEP, this feature is particularly powerful as it allows enums constants to be carrier of generic type information, which can then be fed back to the infere

Re: [enhanced enums] - end of the road?

super(name, ordinal); ... } public void accept(String s) { ... } } The "super" keyword in enum declaration could only designate a class in the same compilation unit - the enum member static class. Hm... Regards, Peter On 05/23/2017 07:49 PM, Maur

Re: [enhanced enums] - end of the road?

I get what you are saying. But I think this intermediate supertype feels too magic. After all, you're after a sneaky way to extend from an enum - which is not something you can do in the source code. If it was possible, then you could just add the supertype yourself e.g. enum Option { D exte

Re: [enhanced enums] - end of the road?

On 15/06/17 15:43, Peter Levart wrote: Hi Maurizio, On 06/15/2017 03:55 PM, Maurizio Cimadamore wrote: I get what you are saying. But I think this intermediate supertype feels too magic. After all, you're after a sneaky way to extend from an enum - which is not something you can do i

Re: [enhanced enums] - end of the road?

terms of reading the resulting code (in which the state of the enum becomes spread across multiple places), I'm not sure if where we end up is better than where we started from. Maurizio On 15/06/17 17:12, Peter Levart wrote: On 06/15/2017 04:53 PM, Maurizio Cimadamore wrote: I think there i

[patterns] on treatment of null

Hi, over the last few weeks we've been exploring the twisted relationship between patterns and nulls. This document: http://cr.openjdk.java.net/~mcimadamore/nulls-patterns.html provides some (hopefully helpful) insights into what the design space looks like. tl;dr; Looks like trying to for

Re: [patterns] on treatment of null

On 07/07/17 15:13, Guy Steele wrote: On Jul 7, 2017, at 8:56 AM, Maurizio Cimadamore wrote: Hi, over the last few weeks we've been exploring the twisted relationship between patterns and nulls. This document: http://cr.openjdk.java.net/~mcimadamore/nulls-patterns.html provides

Re: [patterns] on treatment of null

sed on our experience it works well in practice, but it’s not clear how applicable our experience would be in Java. Best regards, Dmitry On 7 Jul 2017, at 14:56, Maurizio Cimadamore wrote: Hi, over the last few weeks we've been exploring the twisted relationship between patterns

Re: [patterns] on treatment of null

On 07/07/17 17:04, Dmitry Petrashko wrote: On 7 Jul 2017, at 17:17, Maurizio Cimadamore wrote: I understand. In our mind, 'var' is simply a way to tell the compiler "type missing here, please fill it out" - and we'd like to keep the type inference as or

Re: Condy bsm should be idempotent

Well spotted - this would be an issue for my bytecode API too (currently my API is assuming that if two condy CP entries are the same, only one entry has to be written in the resulting classfile stream). Maurizio On 17/08/17 17:15, Remi Forax wrote: Hi all, have some of you may know, i've st

Re: Remi's fear of the constabulatory

On 04/09/17 17:38, Brian Goetz wrote: These send a clear signal to the caller about what sort of arguments can be passed (though the compiler still need to apply additional constraints, such as the constables being compile-time constant expressons.) You could validly argue either way; that "

Re: My lambda leftovers

While I sympathize with the proposal, I think making 'throw' an expression is trickier than it seems; in Java expression have types - if we make 'throw' an expression, then we must state what type does it have. In Scala the Nothing type is used for this purpose; Java doesn't have such a type. T

Re: My lambda leftovers

can be a constant pattern in which case you get the old good 'case'). Maurizio Rémi - Mail original - De: "Maurizio Cimadamore" À: "Brian Goetz" , "Tagir Valeev" , "Remi Forax" Cc: "amber-spec-experts" Envoyé: Lundi

Re: Data classes

Hi Mark, the code that is generated on a datum is essentially like real code that you would otherwise have typed yourself. In other word, think of it as ACC_MANDATED, not as ACC_SYNTHETIC. It is something that the compiler can fully reason about during type-checking and, as a consequence, it m

Re: Local variable inference and anonymous class

FTR, this is not just about lambdas and Java 8 in general, this behavior is there since inner classes were added: String s = new Object() { String s }.s; and, after Java 5: id(Z z) { return z; } String s = id(new Object()).s; And then of course in Java 8 the inference enhancement allows for

Re: Raw string literals and Unicode escapes

On 26/02/18 20:17, John Rose wrote: Any*finite choice* of end-quotes has the same problem, with a non-zero probability that decreases (but does not vanish) with the number of available end-quotes. The only way to break out of the box is to allow the user an unlimited range of successively "st

Re: Raw string literals and Unicode escapes

it? Identifiers don’t have a limit. 3.8. Identifiers An identifier is an *unlimited-length sequence* of Java letters and Java digits, the first of which must be a Java letter. — Jim On Feb 26, 2018, at 5:29 PM, Maurizio Cimadamore <mailto:maurizio.cimadam...@oracle.com>> wrote: On 2

Re: Raw string literals and Unicode escapes

I stand corrected - repeated underscores are allowed - but Josh's example reminded me of the state of affair with raw strings. Maurizio On 26/02/18 22:57, Maurizio Cimadamore wrote: At least there were other cases were we found different trade off between expressiveness and practic

Re: Raw string literals and Unicode escapes

On 27/02/18 08:16, fo...@univ-mlv.fr wrote: Hi John, see below. - Mail original - De: "John Rose" À: "Remi Forax" Cc: "amber-spec-experts" Envoyé: Lundi 26 Février 2018 21:17:13 Objet: Re: Raw string literals and Unicode escapes On Feb 26, 2018, at 10:43 AM, Alex Buckley wrote: O

Re: break seen as a C archaism

So, from a language design perspective, 'return x' is wrong - but, as you point out, we already committed the original sin of having 'return == local return' for lambdas, so I'm not too convinced that we couldn't use the same story again here. E.g. when you say 'return', what you really mean is

Re: break seen as a C archaism

Hi Peter, John, I think I found your arguments convincing, both from a technical point of view - the stack analogy was a good one, and from a programming model point of view - declaration vs. block of code. I believe these are good basis for why we should break away from what we have chosen to

Re: How to implement a record de-constructor ?

Just a digression on your premise - it's true that records hide a bit of the need for explicit deconstruction; but if you are a fan of the 'you don't need abstract records' camp (as I am :-)), I believe that means that you have to make up for the lack of abstract records with some kind of custo

Re: JEP325: Switch expressions spec

Looks neat. Some comments: * I note that you introduced patterns to describe the new syntactic options; while that's a completely fine choice, I wonder if it could lead to confusion - I always thought of JEP 325 as a set of standalone switch improvements, which don't need the P-word to be just

Re: [constables] RFR of constants API

The [Type, Method, Field]Descriptor API looks neat - I have two comments on this: * I believe the name descriptor is going to be confusing with the rest of the API, as there are a lot of classes whose name ends with 'Desc' * we discussed internally to sprinkle parameters on java/lang/reflect

Re: Treatment of nested 'break'

On 08/05/18 23:37, Dan Smith wrote: I think what prompted this degree of brittleness is worries about ambiguity between label breaks and value breaks. Let me suggest this disambiguation strategy instead (in the spirit of 6.5.2): - If an unqualified name appears immediately after a 'break' and

Re: [constables] RFR of constants API

On 11/05/18 15:33, Brian Goetz wrote: * I believe the name descriptor is going to be confusing with the rest of the API, as there are a lot of classes whose name ends with 'Desc' I think this speaks to these classes ({Type,Field,Method}Descriptor) being in the wrong place.  I think they s

Re: Extending 15.28 to include toString() on an enum constant

Remi is correct - 303 has the potential to special case toString() method calls on enums. One thing that 303 lacks, at least at the moment, is the ability to redefine what goes into places where a constant expression is expected (case labels, annotations, ...). That is, the additional constant

Re: JEP draft: Concise Method Bodies - extend this to local functions?

On 20/09/18 17:32, Remi Forax wrote: There is also a potential confusion between   Function fun() = Utils::bar; and   Function fun() -> Utils::bar; You meant between Function fun() = Utils::bar; and Function fun = Utils::bar; ? (first is method body, second is variable initializer) Mau

Re: New JEP: Concise Method Bodies

On 20/09/18 20:05, Kevin Bourrillion wrote: In this case, I think the `=/` /form /might/ also clear that bar because of the automatic parameter pass-through. But I cannot currently see how the `->` form comes close to clearing it. Not sure I get it - surely every getter might benefit form thi

Re: JEP draft: Concise Method Bodies - extend this to local functions?

On 20/09/18 21:22, Alex Buckley wrote: On 9/20/2018 1:08 PM, Maurizio Cimadamore wrote: On 20/09/18 17:32, Remi Forax wrote: There is also a potential confusion between   Function fun() = Utils::bar; and   Function fun() -> Utils::bar; You meant between Function fun() = Utils::bar;

Re: Can switch expression be compile-time constant?

One small point, as I've recently discussed this with Jan. Tagir, you are asking two questions :-) 1) Should a switch expression (of the right kind) be treated as a 'constant expression' (as per 15.28) ? 2) Should javac opportunistically fold away dead code when it can detect so? The answer

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

On 27/11/2018 02:04, John Rose wrote: In source code the simple names can be obtained by using an import which mentions NH:  `` import pkg.NH.* ``.  So there's no great source-level advantage to having the top-level names (package members) instead of the nested names (class members).  Maybe t

enhanced enums - back from the dead?

Hi, as mentioned in [1], the work on enhanced enum stopped while ago as we have found some interoperability issues between generic enums and standard enum APIs such as EnumSet/EnumMap. Recently, we have discussed a possible approach that might get us out of the woods, which is described in gr

Re: enhanced enums - back from the dead?

ion you're asking, I just hate saying something wrong without correcting it. :-) On Wed, Dec 5, 2018 at 11:26 AM Kevin Bourrillion <mailto:kev...@google.com>> wrote: On Wed, Dec 5, 2018 at 8:19 AM Maurizio Cimadamore mailto:maurizio.cimadam...@oracle.com>> wrote:

Re: enhanced enums - back from the dead?

h("-all", it -> bean.all = true) .parse(List.of(args)); } } regards, Rémi - Mail original - De: "Maurizio Cimadamore" À: "amber-spec-experts" Envoyé: Mercredi 5 Décembre 2018 17:14:59 Objet: enhanced enums - back from the dead? Hi, as mentioned i

Re: enhanced enums - back from the dead?

On 06/12/2018 16:53, fo...@univ-mlv.fr wrote: - Mail original - De: "Maurizio Cimadamore" À: "Remi Forax" Cc: "amber-spec-experts" Envoyé: Jeudi 6 Décembre 2018 09:54:09 Objet: Re: enhanced enums - back from the dead? Hi Remi, some comments inline. O

Re: enhanced enums - back from the dead?

var bean = new Object() { Path input = Path.of("input.txt"); boolean all = false; }; new LineParsing() .with("-input", it -> bean.input = Path.of(it.next())) .with("-all", it -> bean.all = true) .parse(Lis

Re: enhanced enums - back from the dead?

On 08/12/2018 12:45, fo...@univ-mlv.fr wrote: - Mail original - De: "Maurizio Cimadamore" À: "Remi Forax" Cc: "amber-spec-experts" Envoyé: Samedi 8 Décembre 2018 00:57:58 Objet: Re: enhanced enums - back from the dead? [...] It's not that i do

Re: enhanced enums - back from the dead?

Thanks for the data - I guess the takeaway is that, as expected, making type-checking of raw typing sharper will help migration (e.g. add type parameters to  existing code that might use some generic signatures already), but it comes at the cost of some source incompatibility. If we restrict t

Re: enhanced enums - back from the dead?

On 10/12/2018 23:58, Brian Goetz wrote: 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

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

; so while we could fix our JDK types, we could not fix all the other code with similar signatures. Which is what has sent us in a different direction. Thanks Maurizio I'm sure there's a lot that I've overlooked, this is quite difficult to reason about in the abstract.

Re: enhanced enums - back from the dead?

Sorrt for the very late reply - yesterday I was writing this, but got hijacked by Xmas party :-) On 12/12/2018 16:40, Kevin Bourrillion wrote: What proportion of enum use cases benefit from this? Offhand, I would have to guess that it is less than 0.1% (and if it turned out to be /far/ less i

Re: Call for bikeshed -- break replacement in expression switch

On 16/05/2019 21:04, Brian Goetz wrote: The notion of “reserved word” is insufficiently precise.  More precisely, yield is a _reserved type identifier_, like `var`.  That means that you cannot have a class called `yield`, but you can have local variables, or methods, or fields, or type variabl

Re: Call for bikeshed -- break replacement in expression switch

On 16/05/2019 21:46, John Rose wrote: On May 16, 2019, at 1:34 PM, Maurizio Cimadamore wrote: On the other hand is a trivial one to resolve, given what we're discussing now is something like "yields" EXPRESSION so, as soon as the compiler sees a "(" it will s

Re: Draft JLS spec for records

Nits * in 8.10.1: "Each record component in the /RecordHeader/ declares one |private final| field in the record class whose name is same as the /Identifier/ in the record component." This seems a bit early. Also, you repeat the same in 8.10.3, which is arguably a much better place? * Also

Re: Draft JLS spec for records

On 03/09/2019 22:00, Alex Buckley wrote: The private fields aren't synthetic (generated by a compiler as a private implementation detail), they're mandated ("implicitly declared"). 8.10.3 says that the implicitly declared fields have the annos from the components, great, done. You are righ

Re: record components as a first class reflection element

Question - should RecordComponent extend java.lang.reflect.Member (after all, it has a name and a type). Not 100% sure. Maurizio On 24/09/2019 20:33, Alex Buckley wrote: At first glance, this is sensible because of the first-class status in the JLS of record components and their mapping to acc

Re: JDK-8227870 - Escape Sequences For Line Continuation and White Space (Preview)

Hi, in general I see where the enhancements are coming from - but I do have some comments. One is pedagogical; I think a world where single line strings are denoted by a single double quote, whereas multi line strings are denoted by triple double quotes is a relatively wimple world for the us

Re: JDK-8227870 - Escape Sequences For Line Continuation and White Space (Preview)

On 30/09/2019 16:36, Jim Laskey wrote: In line. On Sep 30, 2019, at 12:29 PM, Maurizio Cimadamore <mailto:maurizio.cimadam...@oracle.com>> wrote: Hi, in general I see where the enhancements are coming from - but I do have some comments. One is pedagogical; I think a world whe

Re: JDK-8227870 - Escape Sequences For Line Continuation and White Space (Preview)

On 30/09/2019 16:59, Brian Goetz wrote: One is pedagogical; I think a world where single line strings are denoted by a single double quote, whereas multi line strings are denoted by triple double quotes is a relatively wimple world for the user to grok. This proposal effectively blurs the lin

Re: [sealed] Sealed local classes?

Good catch! I fully support the restriction. In your other email I guess you are referring to anonymous classes implementing a sealed interface, right? E.g. sealed interface Foo {     void m();     /* static final */ Foo f1 = new Foo() { ... }     /* static final */ Foo f2 = () -> {}; } Tha

Re: [sealed] Sealed local classes?

On 10/10/2019 01:50, Brian Goetz wrote: Right. We already restrict anon and lambda instances of the sealed type. Not only can't we stably write down their types in the PS attribute, but even if we could, it's so easy to accidentally lose exhaustiveness. This is a very good point; if I have

Re: Record Component attributes

On 09/10/2019 19:34, Remi Forax wrote: - Mail original - De: "Remi Forax" À: "Brian Goetz" Cc: "amber-spec-experts" Envoyé: Mercredi 9 Octobre 2019 18:44:23 Objet: Re: Record Component attributes - Mail original - De: "Brian Goetz" À: "Remi Forax" , "amber-spec-experts"

Re: sample javadoc output for records and sealed types.

I think the output looks very clean. On the 'sealed' part I have no objectctions. On records, what you did looks, again, very clean. The only comment I have there is that it "feels" like something is missing in the summary section... e.g. for some reason I would expect a "record components su

Re: [sealed] Sealed local classes?

extending sealed interfaces? E.g.: sealed interface X permits Foo {} enum Foo implements X { // can we do this? A {}, // and what about this? Here we have an additional subclass at runtime. Or we should explicitly declare "non-sealed enum Foo" to allow this? B, C } With best

Re: sample javadoc output for records and sealed types.

On 11/10/2019 15:11, Brian Goetz wrote: On records, what you did looks, again, very clean. The only comment I have there is that it "feels" like something is missing in the summary section... e.g. for some reason I would expect a "record components summary" there. I noted that you lifted th

Re: Record attribute binary format

On 11/10/2019 22:19, fo...@univ-mlv.fr wrote: - Mail original - De: "Brian Goetz" À: "Remi Forax" , "amber-spec-experts" Envoyé: Vendredi 11 Octobre 2019 22:57:23 Objet: Re: Record attribute binary format No need.  Varargs-ness is reified with the (mandated) canonical ctor. hum, th

Re: Record attribute binary format

On 12/10/2019 02:36, Vicente Romero wrote: On 10/11/19 6:50 PM, Maurizio Cimadamore wrote: On 11/10/2019 22:19, fo...@univ-mlv.fr wrote: - Mail original - De: "Brian Goetz" À: "Remi Forax" , "amber-spec-experts" Envoyé: Vendredi 11 Octobre 2

Re: Record attribute binary format

On 12/10/2019 22:17, fo...@univ-mlv.fr wrote: BTW, Should java.lang.Class have a method getCanonicalRecordConstructor() ? This would be helpful, as the serialization use case already shows us that people would want to infer the signature of the canonical descriptor from the accessors return

Re: instance initializer

Hi Peter, we've been thinking more about this... as it was noted in this thread, perhaps the biggest value of 'lone' instance initializers is that they contain _common_ initialization code that is replicated across _all_ constructors. Do we need this for records? Probably no, we don't - the re

Re: [sealed] Sealed interface as a utility class?

Hi Tagir, I think think that what you are asking for is more along the lines of having "final interface" rather than sealed which permits nobody. Right? I agree that it could be worth re-examining the restriction that interfaces cannot be marked as final; I think that restriction comes from w

Re: Draft JLS spec for JEP 305: Pattern matching for instanceof

Hi Gavin, looks good, and I note that you also tweaked instanceof to use a "bi-modal" semantics - e.g. instanceof Type | Pattern. On that note, I find that the section which speaks about 'type instance of' could use same cleanup you did on patterns: " If a cast of the /RelationalExpression/

Re: Draft JLS spec for JEP 305: Pattern matching for instanceof

Looks good, thanks Maurizio On 21/10/2019 13:02, Gavin Bierman wrote: Thanks Maurizio. I have tweaked the two definitions to be more clearly aligned. Gavin On 21 Oct 2019, at 10:57, Maurizio Cimadamore <mailto:maurizio.cimadam...@oracle.com>> wrote: Hi Gavin, looks good, and I

Re: forbidding serialization methods as members of records

On 31/10/2019 14:09, Jonathan Gibbons wrote: On 10/31/19 5:25 AM, Chris Hegarty wrote: On 31 Oct 2019, at 12:21, Vicente Romero wrote: Hi, In the past we discussed about forbidding the declaration of some serialization related methods in records. In particular:   writeObject(ObjectOu

Re: Updated Draft specs for JEP 359 (Records)

Related to the earlier discussion on forbidden record members - how is this section still relevant? "It is a compile-time error for a record declaration to declare a record component with the name |clone|, |finalize|, |getClass|, |hashCode|, |notify|, |notifyAll|, |readObjectNoData|, |readReso

Re: Updated Draft specs for JEP 359 (Records)

ould apply there? Maurizio On 31/10/2019 14:29, Maurizio Cimadamore wrote: Moreover, a deeper question: should we leave the magic auto-initialization of fields only for the compact form? That way, you would have a _new_ linguistic form, with _new_ properties, whereas old forms (e.g. a constr

Re: Updated Draft specs for JEP 359 (Records)

On 31/10/2019 16:11, Chris Hegarty wrote: On 31 Oct 2019, at 15:29, Brian Goetz wrote: "It is a compile-time error for a record declaration to declare a record component with the name |clone|, |finalize|, |getClass|, |hashCode|, |notify|, |notifyAll|, |readObjectNoData|, |readResolve|, |

Re: question about java.lang.reflect.RecordComponent API

Hi Vicente, some random thoughts below. 1) A record component is *neither* a field, *nor* a method parameter. So, IMHO we should resist to all siren songs pushing for consistency in this or that direction. The spec is very clear on that: "A record type R has the following members:     For ea

Re: Updated Draft specs for JEP 359 (Records)

Hi Gavin, looks great - some minor comments: * I'm having problem parsing this sentence "An explicitly declared accessor method is not annotated with any applicable annotation that appears on the corresponding record component." What do you mean exactly? I guess you mean that the explicit acc

Re: Updated Draft specs for JEP 359 (Records)

+1 - I like this. We now define precisely what an accessor and a canonical constructor are - and then rule some of the explicit declarations out, with no room for ambiguities. Great job. Maurizio On 25/11/2019 23:50, Brian Goetz wrote: The approach is much improved. I like that it casts a w

Re: Clarifying record reflective support

Hi Chris, I like your proposal; first, it makes isRecord/getRecordComponents in sync with other similar pair of methods like isArray/getComponentType. Secondly, it allows tighter tests to be written e.g. by the JCK team, which is, I think, where the value really is. In your updated sped we sa

Re: Updated Draft specs for JEP 359 (Records)

+1 Maurizio On 03/12/2019 13:00, Gavin Bierman wrote: I have made a further change to the online version. There was a missing case in 8.10.3, as it should be required that an explicitly declared accessor method is not static. Gavin gbierman$ hg diff -c 30704:012cc50cb363 diff -r 9f5a2133411

Re: Clarifying record reflective support

On 03/12/2019 17:15, Brian Goetz wrote: I am not even sure if “has a record attribute” isn’t overkill. “Is a record class” is the more proper semantic specification, and it’s not clear to me that reflection api spec is the place to record these things. Should reflection speak about 'has a

Re: Clarifying record reflective support

no record component because i'm not a record, isRecord is exactly the kind of method you want to call. regards, Rémi ----- Mail original - De: "Chris Hegarty" À: "amber-spec-experts" , "joe darcy" , "Maurizio Cimadamore" Envoyé: Mardi 3 Décembre

Re: Clarifying record reflective support

On 04/12/2019 00:17, fo...@univ-mlv.fr wrote: I don't follow you, conceptually a pattern matching is an optional of tuples (i don't want to go more deep than that given that the real implementation is still in flux), you can construct an optional if getReturnComponents() returns null or not.

Re: Clarifying record reflective support

On 04/12/2019 15:53, fo...@univ-mlv.fr wrote: Like getEnumConstants(), this is an argument i can agree upon. Yes, that is the important precedent here. But during the scanning of the methods of java.lang.Class, i've discovered that describeConstable() already returns an Optional. describeCo

Re: [sealed] Changes to type system

Hi Gavin, the proposal makes sense to me - it seems like enhancing "side-cast" conversion rules to take sealed-ness into account is a natural extension of what we have; I'm not too worried about compiler performances; cast conversion is already a pretty complex routine as far as type relations

Re: [sealed] Changes to type system

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 if that's the case, I have to admit that I find it a bit awkward that I can use j

Re: getPermittedSubclasses() on j.l.rClass returning an array of ClassDesc

On 11/05/2020 18:10, Brian Goetz wrote: The core reflection API has historically been happy to ignore those corner cases. Instead, it's designed for the typical situation where everything is consistent and available. You're somewhat uncomfortable with this design choice, which is fair, but

Re: Finalizing in JDK 16 - Pattern matching for instanceof

On 26/08/2020 16:00, Brian Goetz wrote: While I get why some people would like to bootstrap this into an argument why the pattern semantics are wrong, the key observation here is: _both of these questions are stupid_.  So I think there's an obvious way to fix this so that there is no problem h

Re: [records] Is C-style array declaration in components dropped?

+1 on this - as Brian says - part of a long-term battle against old syntax - note that at some point in Java 7 we dropped support for C-style array syntax on varargs decl - e.g.: void m(int n, String... args[]) See: https://bugs.openjdk.java.net/browse/JDK-6569633 Maurizio On 24/07/2020 13:4

Re: The Record Attribute - What does it mean to be a record at runtime?

I think the point Chris is raising is a bit more subtle. The VM has a notion of classes in which final fields are trusted - when that happens, the value of final fields are constant folded by the JIT (yayy!). There is a problem though: in practice, final fields can be mutated e.g. by reflect

Re: The Record Attribute - What does it mean to be a record at runtime?

For me, you are focusing on the wrong side of the time line, trusted final fields should be the new normal and plain old classes are the ones that are weird because they have a *weak* final fields semantics. So instead of saying that records, hidden classes, anonymous classes (and soon primi

[statics] allowing static initializers in interfaces?

Hi, now that the work on allowing static members in nested declarations [1] is wrapping up, I'm wondering if we could add treatment for one more case: static initializers in interfaces. This seems a case where the static compiler is already inserting static blocks (to initialize any static fie

Re: Relaxed assignment conversions for sealed types

On 31/10/2020 23:30, Brian Goetz wrote: On Oct 25, 2020, at 10:06 AM, Brian Goetz > wrote: To make it clear that I'm not talking about the annoyance of typing the cast, let's pretend I'm suggesting to write it like this:     BarImpl bi = (__static BarImpl) b

Re: Relaxed assignment conversions for sealed types

On 24/11/2020 14:45, Remi Forax wrote: *De: *"Maurizio Cimadamore" *À: *"Brian Goetz" , "Tagir Valeev" *Cc: *"amber-spec-experts" *Envoyé: *Mardi 24 Novembr

Re: Should final fields in records be trusted or not trusted in 16?

What Chris says. The immediate problem is that the Javadoc for Field::set is incorrect. Fixing it by mentioning presence of a bytecode attribute somewhere is not really a fix. Having better treatment for final fields for more classes is a noble goal - having restricted classes like records w

Re: Should final fields in records be trusted or not trusted in 16?

On 10/12/2020 14:11, fo...@univ-mlv.fr wrote: I disagree, having the VM behaving strictly like Java is a hack. Microsoft has done that with .Net generics which are C# generics. I don't see the point of repeating the errors of the past. I think you are missing my broader point. I don't think

Re: Nullity (was: Pattern features for next iteration)

This seems a very nice twist - while slightly more verbose, what we get back is that patterns "say what they mean", and there's no subtle type dependency analysis which determines the fate of null. This had me a bit worried, since this creates an action-at-a-distance between the type of the tar

Re: Nullity (was: Pattern features for next iteration)

realize that I have read too much between the lines. Maurizio On 1/21/2021 2:15 PM, Maurizio Cimadamore wrote: This seems a very nice twist - while slightly more verbose, what we get back is that patterns "say what they mean", and there's no subtle type dependency analysis whi

Re: [External] : Re: The good and the bad static pattern ?

On 21/01/2021 16:13, fo...@univ-mlv.fr wrote: OK, so it is the "target to argument shifting" that is weird to you?  That when we declare a static pattern, there is a special first argument that is the target ? The sementics implies an instanceof on something which is not not visi

Re: Relaxed assignment conversions for sealed types

This is a fruitful direction to explore, as it lets programmers "say what they mean" and provide adequate compiler support for when invariants suddenly change behind the user's backs. +1 Maurizio On 22/01/2021 17:27, Brian Goetz wrote: meant "I assert this case is total, please error if not.

Re: Two new draft pattern matching JEPs

Looks good - some comments below (I apologize if some of these have been raised elsewhere): ## Patterns in switch * In the general intro, maybe you could link this: https://bugs.openjdk.java.net/browse/JDK-4032356 or this: https://bugs.openjdk.java.net/browse/JDK-7127722 Which are all insta

Re: Guards

This seems like a nice landing. The unification of guards and AND patterns was clever, and clearly compositional, but exposing AND patterns just to get to guards can seem a daunting step. I agree that the priority, language design-wise is to get the combo switch/case and if/instanceof on rou

Re: Guards

Hi Brian On 05/03/2021 23:11, Brian Goetz wrote: I have long had a nagging feeling that this will eventually be desirable.  Let's say we have P & g & Q & h; under what conditions can we commute g and Q without regret?  I can think of four potential sources of regret:  - g declares bindings t

Re: Type pattern and raw type

On 15/03/2021 13:28, Brian Goetz wrote: Unchecked conversions are forbidden because of type pollution, that why you can not write if (o instanceof Foo foo) { Raw type conversions also leads to type pollution, so i think that a type pattern with a raw type should be forbidden too. Note s

Re: Looking ahead: pattern assignment

On 12/03/2021 19:58, Brian Goetz wrote: 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 has to take, and the constraints around it. Yes please! :-) Just as we were successfully able t

  1   2   >