Re: Spec draft for JEP 286 Local Variable Type Inference

Hi Dan, Looks great ! In 14.4.1, a minor remark, i had to look for what standalone expression is, not poly expression seems better for me so i suggest that Because the initializer is a standalone expression, an error occurs if it is a lambda expression (15.27) or a method reference expression

Using Condy to calculate a method/field descriptor

How far we are from using Condy as a computable String to represent a field/method descriptor, this may be useful for representing reified generics if a descriptor can be calculated from something representing a type argument. At least, it's a good replacement for the things i do currently with

Condy bsm should be idempotent

Hi all, have some of you may know, i've started to implement ConstantDynamic in ASM, and the spec currently breaks an invariant of ASM that i would like to keep. ASM API do not expose the constant of the constant pool, it provides methods that decode/encode instructions that as a side effect

My lambda leftovers

Hi all, The JEP 302 list some improvements but I think some are missing, obviously, it's up to debate :) So here is my list of left leftovers: - support throw statement as a lambda expression I think we have already discussed informally about this one. The compiler should allow to have a

Constable interface should die

Brian ask me to explain my concerns about the Constable interface. The whole constant folding story is like a macro system, it's a limited macro system, but still a macro system. I've developed several macro systems, all have limitations, some limitation that i have introduced voluntarily, some

Local variable inference and anonymous class

I had to persuade myself that the fact that a var with an anonymous class will 'leak' the anonymous type [1] is not an issue. By example, with var foo = new Object() { int i; }; the type of foo is the anonymous class and not Object. In fact, we can already 'leak' the type of an anonymous

Re: Reader mail bag

My note on named parameters: Supporting real named parameters that works with overriding and backward compatibility is hard, but i believe there is a sweet spot. - a method can declare to support named parameters by using a new modifier 'named'. so - all parameters are named or none are, you

switch with several arguments

Should we support a switch with several arguments ? By example: for(int i = 1; i < 100; i++) { System.out.println( switch(i % 3, i % 5) { case (0, 0) -> "FizzBuzz"; case (0, _) -> "Fizz"; case (_, 0) -> "Buzz"; default -> i; }); } Apart

Re: Switching on float/double/long

While we could do 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

Re: Switch expressions -- some revisions

> De: "Brian Goetz" > À: "amber-spec-experts" > Envoyé: Jeudi 14 Décembre 2017 22:22:48 > Objet: Switch expressions -- some revisions > After reviewing the feedback on the proposal for switch expressions, and a bit > of going back to

Re: switch with several arguments

surprised to hear that we’ve thought about it. It is >certainly a very cool extension and makes for some very slick code. >Personally I think it should wait until we have thought about tuples >more generally (which might well be part of a value types enhancement). > >Gavin > >&g

Re: PM design question: Shadowing

It's a step too far, as you said the rules for shadowing are currently the same for all constructs, let's not try to break that unity. Your first example already exist with the current construct: //field i in scope if (o instanceof Integer) { Integer i = (Integer)o; System.out.println(i);

Re: Patterns design question: Nulls

I'm for Option, given Option 2 is not a real Option 2, see below. It's unfortunate that the behavior inside nested patterns is different from the behavior of the switch. As you said, it's the expected semantics and i think it's not a big deal if we do not allow destructuring inside a match (

Re: Data classes

Hi Brian, there is an axis which is not mentioned in this document, the nullablility of the fields, it's somewhat like 'final' because fields should not non nullable by default, it asks the compiler to add codes in the constructors (the calls to requireNonNull) so it can have a not so simple

Re: New JEP: Switch Expressions for the Java Language

Hi Brian, correct me of i'm wrong but there is no discussion about accessing to a local variable in the body of an expression, void m(int x, int y) { return switch(x) { case 0 -> y; // is it allowed, how is it translated ? default -> 0; }; } regards, Rémi - Mail original

Re: New JEP: Switch Expressions for the Java Language

- Mail original - > De: "Brian Goetz" > À: "Stephen Colebourne" , "amber-dev" > > Envoyé: Lundi 11 Décembre 2017 20:59:27 > Objet: Re: New JEP: Switch Expressions for the Java Language > On 12/11/2017 7:04 AM,

Re: Continue in switch

We can twist the semantics of continue or decide to go with another (local) keyword which i think is a better idea here. The syntax will be keyword; which is not a valid syntax for a local variable, so any identifier can be used. Like var, i also think we should choose a name which is not a

Re: Exhaustiveness in switch

> De: "Kevin Bourrillion" > À: "Brian Goetz" > Cc: "amber-spec-experts" > Envoyé: Jeudi 10 Mai 2018 22:44:33 > Objet: Re: Exhaustiveness in switch > * I think that for most occurrences of `default: throw...`, by

Re: Exhaustiveness in switch

- Mail original - > De: "Brian Goetz" > À: "amber-spec-experts" > Envoyé: Jeudi 10 Mai 2018 22:12:37 > Objet: Exhaustiveness in switch > In the long (and indirect) thread on "Expression Switch Exception > Naming", we

Re: [raw-strings] Indentation problem

The is a rule when you design a language, if you can do something in the compiler or in a library, do it in the library :) I do not thing it's a good idea to force the pipe prefix in the spec, and from an IDE point of view, you have to do more analysis but you can recognize the sequence ` ...

Re: [raw-strings] Newline character handling

Hi Tagir, you have miss this line: CR (\u000D) and CRLF (\u000D\u000A) sequences are always translated to LF (\u000A). This translation provides least surprise behavior across platforms. this is also the behavior of Perl, PHP, etc. as a guy that had to write too many shaders in Java recently,

Re: Switch translation, part 2

Hi all, while the proposed translation is a good translation by default, when you can have fallthroughs or guards, if you have none of them, it's not the best translation. [CC John Rose because i may say something stupid] The problem is that the VM doesn't not prune never called cases in a

Re: Raw string literals and Unicode escapes

I'm late in the game but why not using the same system as Perl, PHP, Ruby to solve the Lts [1], i.e you have a sequence that says this is the starts of a raw string (%Q, qq, m) then a character (in a predefined list), the raw string and at the end of the raw string the same character as at the

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

De: "Brian Goetz" À: "amber-spec-experts" Envoyé: Mardi 21 Août 2018 13:57:51 Objet: Fwd: Small things Java lets you do, but not everywhere. BQ_BEGIN Received via the spec-comments list. Not a comment on any specific extant project; instead, a wish-list, and mostly stuff we’ve seen

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

Please before submitting a wishlist, please take a look at this video that explain what can be the cost of a change (even if in this case, it's a really small change it's only a VM change) [ https://www.youtube.com/watch?v=-k_IicifbxQ | https://www.youtube.com/watch?v=-k_IicifbxQ ] regards,

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

[this was sent to the amber-spec-comment] Hi Daniel, - Mail original - > De: "Daniel Trebbien" > À: "amber-spec-comments" > Envoyé: Lundi 9 Juillet 2018 02:43:00 > Objet: Extending 15.28 to include toString() on an enum constant > One small idea I have for enhancing the Java language

Re: Updated Constables and constant folding doc

- Mail original - > De: "Remi Forax" <fo...@univ-mlv.fr> > À: "Brian Goetz" <brian.go...@oracle.com> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Mardi 13 Mars 2018 00:10:43 > Objet: Re: Upd

Re: break seen as a C archaism

- Mail original - > De: "Guy Steele" > À: "mark" > Cc: "amber-spec-experts" > Envoyé: Jeudi 15 Mars 2018 20:18:34 > Objet: Re: break seen as a C archaism >> On Mar 15, 2018, at 3:06 PM, Mark Raynsford

Re: break seen as a C archaism

- Mail original - > De: "mark" > À: "amber-spec-experts" > Envoyé: Jeudi 15 Mars 2018 20:06:40 > Objet: Re: break seen as a C archaism > On 2018-03-15T14:50:45 -0400 > Brian Goetz wrote: >> >> > If you are

Re: break seen as a C archaism

- Mail original - > De: "Guy Steele" > À: "Brian Goetz" > Cc: "amber-spec-experts" > Envoyé: Jeudi 15 Mars 2018 20:12:56 > Objet: Re: break seen as a C archaism >> On Mar 15, 2018, at 2:50 PM, Brian

Re: break seen as a C archaism

> De: "John Rose" > À: "Guy Steele" > Cc: "amber-spec-experts" > Envoyé: Jeudi 15 Mars 2018 23:06:51 > Objet: Re: break seen as a C archaism > On Mar 15, 2018, at 2:44 PM, Guy Steele < [

Re: break seen as a C archaism

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

Re: Compile-time type hierarchy information in pattern switch

- Mail original - > De: "Brian Goetz" > À: "Tagir Valeev" , "amber-spec-experts" > > Envoyé: Jeudi 5 Avril 2018 21:44:30 > Objet: Re: Compile-time type hierarchy information in pattern switch >> Is it too

Re: Switch expressions -- gathering the threads

> De: "daniel smith" > À: "Brian Goetz" > Cc: "amber-spec-experts" > Envoyé: Mardi 10 Avril 2018 21:34:13 > Objet: Re: Switch expressions -- gathering the threads >> On Apr 9, 2018, at 1:14 PM, Brian Goetz <

Re: Expression switch - an alternate proposal

Do we need fallthrough in an expression switch, i believe like Stephen that we don't. First, as Stephen point in it's example, if we have comma separated cases, we need less fallthrough and even if we have a code like this var value = switch(x) { case 0: foo(); case 1:

Re: [records] Ancillary fields

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

Re: Feedback wanted: switch expression typing

I do not see (B) as sacrifying the consistency because the premise is that an expression switch should be consistent with ?: But an expression switch can also be modeled as a classical switch that returns it's value to a local variable. int a = switch(foo) { case 'a' -> 2; case 'b'

Re: Expression switch exception naming

> De: "Brian Goetz" > À: "Kevin Bourrillion" > Cc: "amber-spec-experts" > Envoyé: Vendredi 30 Mars 2018 19:48:03 > Objet: Re: Expression switch exception naming >> Although the depth of this debate may seem to have

Re: Expression switch exception naming

You still have not explain why you want to recover from one of these exception knowning that it's simpler to add a default if you want to take care of an unknown enum constant. Rémi - Mail original - > De: "Brian Goetz" > À: "Kevin Bourrillion"

Re: Records -- current status

- Mail original - > De: "Guy Steele" > À: "Brian Goetz" > Cc: "amber-spec-experts" > Envoyé: Jeudi 29 Mars 2018 21:25:56 > Objet: Re: Records -- current status > I've always assumed that, eventually,

Re: Expression switch exception naming

An enum class is always sealed, there is a fixed number of constants values, and there is also a fixed number of subtypes, otherwise values() is not correctly implemented. Rémi - Mail original - > De: "Doug Lea" > À: "Brian Goetz" > Cc:

Re: Records -- current status

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

Re: Records -- current status

> De: "Kevin Bourrillion" > À: "Brian Goetz" > Cc: "amber-spec-experts" > Envoyé: Vendredi 16 Mars 2018 23:36:53 > Objet: Re: Records -- current status [...] >>> OK, but do you have an opinion on whether records

How to implement a record de-constructor ?

While a de-constructor is not strictly needed until we want to serialize a record or do Pattern matching on it, i think it can be useful to share what i think about implementing a de-constructor. Technically a de-constructor is the inverse operation of a constructor (hence the name), instead

Re: Records -- current status

> De: "Guy Steele" > À: "Brian Goetz" > Cc: "amber-spec-experts" > Envoyé: Mardi 20 Mars 2018 16:29:23 > Objet: Re: Records -- current status >> On Mar 20, 2018, at 10:15 AM, Brian Goetz < [

Re: Disallowing break label (and continue label) inside an expression switch

> Envoyé: Vendredi 2 Mars 2018 20:45:52 > Objet: Re: Disallowing break label (and continue label) inside an expression > switch > On Mar 2, 2018, at 8:12 AM, Brian Goetz < [ mailto:brian.go...@oracle.com | > brian.go...@oracle.com ] > wrote: >> Do we disallow the "break TOP" and return in the

Re: Raw string literals and Unicode escapes

> De: "Guy Steele" > À: "John Rose" > Cc: "amber-spec-experts" > Envoyé: Mardi 27 Février 2018 22:12:14 > Objet: Re: Raw string literals and Unicode escapes >> On Feb 27, 2018, at 4:20 PM, John Rose < [

Disallowing break label (and continue label) inside an expression switch

Hi all, as far as i remember, the current idea to differentiate between a break label and a break value is to let the compiler figure this out, i wonder if it's not simpler to disallow break label (and continue label) inside an expression switch. After all, an expression switch do not exist

Re: New JEP: Concise Method Bodies

> De: "Kevin Bourrillion" > À: "Alex Buckley" > Cc: "amber-spec-experts" > Envoyé: Vendredi 5 Octobre 2018 22:03:53 > Objet: Re: New JEP: Concise Method Bodies > On Mon, Sep 24, 2018 at 10:17 AM Alex Buckley < [ > mailto:alex.buck...@oracle.com > | alex.buck...@oracle.com ] > wrote: >> On

Re: `this` in concise method bodies

- Mail original - > De: "Brian Goetz" > À: "John Rose" > Cc: "amber-spec-experts" > Envoyé: Samedi 13 Octobre 2018 15:22:12 > Objet: Re: `this` in concise method bodies > John makes some good arguments for the value of the :: form of CMBs; > that they raise the level of reuse from

Re: `this` in concise method bodies

oops, it the reply button too soon. Rémi >> De: "John Rose" >> À: "Remi Forax" >> Cc: "Brian Goetz" , "amber-spec-experts" >> >> Envoyé: Samedi 13 Octobre 2018 07:00:09 >> Objet: Re: `this` in concise method bodi

Re: New draft JEP: intrinsics for String::format and Objects::hash (among others)

[move to amber-spec-experts] - Mail original - > De: "Brian Goetz" > À: "amber-dev" > Envoyé: Lundi 22 Octobre 2018 21:45:00 > Objet: New draft JEP: intrinsics for String::format and Objects::hash (among > others) > For those of you following the saga of improved constant folding,

expression switch follow-ups

Hi everybody, i think there are two ideas that worth think about now that the expression switch will be released soon that are not related to the elephant in the room, the pattern matching. First, a statement switch can use the arrow syntax with an expression that throw an expression.

Concise method body + type inference ?

I wonder if the concise method body proposal should not be extended to add parameters types/return type inference in case of overriding methods. The idea is that in case of a method overriding a method or implementing an abstract method the return type and the type parameters are optional like

Concise method / method reference

Hi all, i've played a little bit with the concise method prototype. i think that using '=' to 'assign' a method reference to a method signature - is visually too close to a field assignment. - send the wrong message because there is no assignment at runtime. A way to avoid the issue listed above

Lambda Concise method and void return type

Testing the prototype, i've seen myself using -> null instead of a classical empty method body when i want to have a method that does nothing. class A { void f() -> null; // versus void f() { } } the compiler translates the concise version to aconst_null pop return instead of a plain

Re: New JEP: Concise Method Bodies

> De: "daniel smith" > À: "amber-spec-experts" > Envoyé: Samedi 6 Octobre 2018 01:22:25 > Objet: Re: New JEP: Concise Method Bodies >> On Oct 5, 2018, at 4:18 PM, Brian Goetz < [ mailto:brian.go...@oracle.com | >> brian.go...@oracle.com ] > wrote: >>> Can the expression before the :: refer to

Re: New JEP: Concise Method Bodies

Hi Daniel, - Mail original - > De: "daniel smith" > À: "amber-spec-experts" > Envoyé: Mardi 9 Octobre 2018 18:31:48 > Objet: Re: New JEP: Concise Method Bodies >> On Oct 8, 2018, at 12:14 PM, Dan Smith wrote: >> >> - Type-qualified method ref: if you don't pass 'this' to the method,

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

: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() -> Ut

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

> De: "John Rose" > À: "Brian Goetz" > Cc: "amber-spec-experts" > Envoyé: Jeudi 20 Septembre 2018 15:40:19 > Objet: Re: JEP draft: Concise Method Bodies - extend this to local functions? > On Sep 19, 2018, at 6:23 PM, Brian Goetz < [ mailto:brian.go...@oracle.com | > brian.go...@oracle.com ] >

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

> De: "John Rose" > À: "Brian Goetz" > Cc: "amber-spec-experts" > Envoyé: Jeudi 20 Septembre 2018 15:40:19 > Objet: Re: JEP draft: Concise Method Bodies - extend this to local functions? > On Sep 19, 2018, at 6:23 PM, Brian Goetz < [ mailto:brian.go...@oracle.com | > brian.go...@oracle.com ] >

Re: New JEP: Concise Method Bodies

There is a ';' at the end of dayOfWeek that should not be there. String dayOfWeek(int d) -> switch (d) { case 1 -> "SUNDAY"; case 2 -> "MONDAY"; ... }; // < should be removed Rémi - Mail original - > De: "mark reinhold" > À: "Alex Buckley" > Cc:

Re: Enhancing Java String Literals Round 2

- Mail original - > De: "Brian Goetz" > À: "Jim Laskey" > Cc: "amber-spec-experts" > Envoyé: Dimanche 6 Janvier 2019 18:43:19 > Objet: Re: Enhancing Java String Literals Round 2 > As Reinier pointed out on amber-dev, regex strings may routinely contain > escaped > meta-characters — +,

Re: We need more keywords, captain!

I think i prefer break-with, the problem of break-return is that people will write it break return without the hyphen, break return is in my opinion too close to return if you read the code too fast and a break return without a value means nothing unlike a regular return. I like break-with

Re: Sealed types -- updated proposal

I'm still not 100% sure that mixing the exhaustiveness and the closeness is a good idea, again because - you may want closeness of non user named types - you may want exhaustiveness not only types (on values by example) but it makes the feature simple, so let's go that way. Allowing public

Re: We need more keywords, captain!

My favorite hyphen keyword is short-circuit, i don't know where to use it, but it's so good that we have to find a new feature to introduce it :) As i said, i really like this proposal. The hyphen keywords nicely solve the issue when you want to introduce a keyword in the middle of the code,

nest syntax proposal

Hi all, as Brian said recently, we have an issue because we are shortening the class declaration (with records) or wants to declare in a single compilation unit a hierarchy of types (with sealed types) and currently Java requires that a compilation unit can only have one public class. One

Re: enhanced enums - back from the dead?

There is also a non empty intersection between a sum type and an enum type, obviously you can swith on both of them, but more generally an abstract enum (an enum that uses subclassing) is a specialized version of a sum type. And if we generalize sum types to allow constants, we are bridging the

Re: Flow scoping

- Mail original - > De: "Brian Goetz" > À: "amber-spec-experts" > Envoyé: Mardi 11 Décembre 2018 21:08:38 > Objet: 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. 

Re: enhanced enums - back from the dead?

Hi Maurizio, i think you have overlook the fact that raw types and inference also doesn't play well together. accessibility: Widening the type is usually a big No because of the security implication. The fact that the same code code has no security bug with version n but a security hole with

Re: Sealed types

> De: "Brian Goetz" > À: "amber-spec-experts" > Envoyé: Vendredi 7 Décembre 2018 17:38:53 > Objet: 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

Re: Sealed types

Hi Doug, using colon ':' will cause trouble to people that discover Java after having used C or C# given that ':' is used to introduce supertypes in those languages. Your proposed compact declaration is a mess visually if you declare a subtype which is a sealed interface with a list of

Re: Sealed types

> De: "Brian Goetz" > À: "amber-spec-experts" > Envoyé: Mardi 27 Novembre 2018 23:20:54 > Objet: 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

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

> De: "John Rose" > À: "Kevin Bourrillion" > Cc: "amber-spec-experts" > Envoyé: Mardi 27 Novembre 2018 03:04:01 > Objet: Re: Lifting the restriction on the number of public classes per file > On Nov 26, 2018, at 11:43 AM, Kevin Bourrillion < [ mailto:kev...@google.com | > kev...@google.com ] >

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

> De: "Kevin Bourrillion" > À: "Brian Goetz" > Cc: "amber-spec-experts" > Envoyé: Lundi 26 Novembre 2018 20:43:37 > Objet: Re: Lifting the restriction on the number of public classes per file > Sorry for delay. Can we unpack the "for whatever reason" part? For what > reason? > Unsurprisingly

Re: Flow scoping

> De: "John Rose" > À: "Tagir Valeev" > Cc: "amber-spec-experts" > Envoyé: Mardi 8 Janvier 2019 23:55:19 > Objet: Re: Flow scoping > On Jan 4, 2019, at 6:07 AM, Tagir Valeev < [ mailto:amae...@gmail.com | > amae...@gmail.com ] > wrote: >> For the record: I heavily support this. If then-branch

Re: Flow scoping

It's basically what Swift does, you have a syntactic form for if (x instanceof P(var y)) written if let y = (x as? P)?.y but it can not be inversed/negated (and you can not extract more than one variable easily). so yes the question is where to draw the line. I'm with Brian on this,

Re: Flow scoping

> De: "Tagir Valeev" > À: "Brian Goetz" > Cc: "amber-spec-experts" > Envoyé: Vendredi 4 Janvier 2019 15:07:44 > Objet: Re: Flow scoping > Hello! >> This is certainly this intuition that guided us here; it should be possible >> to >> freely refactor >> if (e) >> throw x; >> else { stuff }

Re: Multiple return values

You can have both ! This is basically what we are doing with lambdas, you have a structural syntax + a named type that are bound together using inference. Let say we have a tuple keyword that means, value + record + constructor/de-constructor tuple Range(int lo, int hi) { … } then you can

Re: String reboot (plain text)

I lke the r prefix because most people think the r prefix means regular expression. Rémi > De: "Brian Goetz" > À: "amber-spec-experts" > Envoyé: Samedi 6 Avril 2019 17:47:25 > Objet: Fwd: String reboot (plain text) > Received on amber-spec-comments. These are mostly comments on syntax

switch statement and lambda

Currently this code doesn't compile IntConsumer c = x -> switch(x) { default -> System.out.println(x); }; I believe it should because this is the basic pattern for supporting the actor model, you consume a message and do a side effect* depending on the type of the message, translated in Java,

Re: Patterns for arrays of specific length

Hi Tagir, - Mail original - > De: "Tagir Valeev" > À: "amber-spec-experts" > Envoyé: Lundi 4 Mars 2019 04:30:09 > Objet: Patterns for arrays of specific length > Hello! > > In intellij IDEA code we often see snippets like this: > > final ResolveResult[] resolveResults =

Re: Patterns for arrays of specific length

It's a poster child for a 'let' expression instead of twisting instanceof to work with no type return let results = multiResolve(false) in results.length == 1 && results[0].isValidResult() ? results[0].getElement() : null; Rémi - Mail original - > De: "Brian Goetz" > À: "Tagir

Re: Updated document on data classes and sealed types

So records are only immutable, it's a bold move and i like that. For beginners we offer a simple model with immutable named tuples and mutable List and Map, very like Python. I still think we should restrict sealed to interface only (you can always retrofit a class or an abstract class to add a

Re: nest syntax alternative

- Mail original - > De: "John Rose" > À: "Brian Goetz" > Cc: "amber-spec-experts" > Envoyé: Mercredi 20 Février 2019 00:52:32 > Objet: Re: nest syntax alternative > On Feb 19, 2019, at 2:50 PM, Brian Goetz wrote: >> >> …we are still left with the same problem of finding the source

Trusted final fields Was: Updated document on data classes and sealed types

As you may know, there are two kinds of final field in Java, you have final fields and trusted final fields, the former are classical final fields the later are final fields that can no be changed by reflection thus are considered as "real" final field by JITs (see

Re: Concise method bodies with delegation and this

> De: "Brian Goetz" > À: "amber-spec-experts" > Envoyé: Lundi 18 Mars 2019 15:19:31 > Objet: Fwd: Concise method bodies with delegation and this > Received on the -comments list. > So, the CMB proposal was a bit of an experiment in letting a half-baked idea > out > of the lab a little sooner

Re: Records and annotations

> De: "Brian Goetz" > À: "Kevin Bourrillion" > Cc: "amber-spec-experts" > Envoyé: Mardi 19 Mars 2019 00:25:58 > Objet: Re: Records and annotations >>> - Should we treat the cases where @A has a target of RECORD_COMPONENT, >>> separately from the cases where it does not, such as, only push the

Re: Updated document on data classes and sealed types

> De: "Kevin Bourrillion" > À: "Amber Expert Group Observers" > Cc: "amber-spec-experts" > Envoyé: Vendredi 15 Mars 2019 22:02:24 > Objet: Re: Updated document on data classes and sealed types > Well, I thought of nothing to dislike about this. 99.9% of users will never > know > or care that

Re: String reboot (plain text)

I really like in the syntax proposed by Jim the fact that the single quote " is retconned to allow several lines, it seems the easiest thing to do if we just want to introduce a multi-lines literal string. >From that, i agree that the more lines you have, the more you need to have a >way to

Re: String reboot (plain text)

About the formatting rules, we can reuse the doc comment trick to use a character to specify the alignment. String html = \" " " " Hello World. "

Re: Sealed types -- updated proposal

You have forgotten that - if you have a sealed class (not sealed interface), using nesting has the side effect of creating inner classes. I don't know what is the policy of Google about inner classes that mix enclosing class access and inheritance but i suppose they are prohibited too. - for

Re: String reboot - (1a) incidental whitespace

It's more or less the javadoc approach no ? Rémi > De: "Guy Steele" > À: "Brian Goetz" > Cc: "amber-spec-experts" > Envoyé: Mercredi 10 Avril 2019 23:36:34 > Objet: Re: String reboot - (1a) incidental whitespace >> On Apr 10, 2019, at 4:54 PM, Brian Goetz < [ mailto:brian.go...@oracle.com

records are dead long live to ...

I've re-read the current state of the record (ex datum) http://cr.openjdk.java.net/~briangoetz/amber/datum.html trying to explain to myself how it works. At the end of section "Why not "just" do tuples ?", you have this gem, "A good starting point for thinking about records is that they are

Make Primary Constructor an independant feature

I think there is a merit to separate the primary constructor feature from other features of a record. This afternoon while fixing a bug, i took a look to the classes around to see if it was possible to transform them to records. But i've found that in more than half of the cases, the classes

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

- Mail original - > De: "John Rose" > À: "Alex Buckley" > Cc: "amber-spec-experts" > Envoyé: Vendredi 17 Mai 2019 03:15:36 > Objet: Re: Call for bikeshed -- break replacement in expression switch > On May 16, 2019, at 2:43 PM, Alex Buckley wrote: >> >> If you're proposing to

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

- Mail original - > De: "Guy Steele" > À: "Maurizio Cimadamore" > Cc: "amber-spec-experts" , "Éamonn > McManus" > Envoyé: Jeudi 16 Mai 2019 23:41:05 > Objet: Re: Call for bikeshed -- break replacement in expression switch >> On May 16, 2019, at 5:05 PM, Maurizio Cimadamore >> wrote:

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

- Mail original - > De: "John Rose" > À: "Brian Goetz" > Cc: "amber-spec-experts" > Envoyé: Vendredi 17 Mai 2019 08:41:20 > Objet: Re: Call for bikeshed -- break replacement in expression switch > (Going back to the start of this thread.) > > On May 12, 2019, at 12:38 PM, Brian Goetz

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

Thanks for providing a clear view of our options. I vote for B. I will add that obviously there is no switchy block that contains an unqualified yield in the actual code so the compiler should emit an error instead of a warning if there is an unqualified yield in the scope of the switchy

Re: Revisiting field references

- Mail original - > De: "Alan Malloy" > À: "amber-spec-experts" > Envoyé: Mardi 4 Juin 2019 00:19:10 > Objet: Revisiting field references Hi Alan, i'm sorry but i've more questions than answers, > Hello, amber-spec-experts. I understand that "field references" is an > idea that was

  1   2   3   4   >