OK, I responded to one corner by pointing out a principle that tends to
align rawness more strongly with multi-line-ness. I guess I should lay
all my cards on the table FTR, and will do so by responding to Brian's
restacking Email and Jim's reboot Email. (I guess today's String-day.)
TL;DR: I ag
And here’s another way to think about it: if a subexpression never completes
normally, then in effect there is unreachable code in the containing
expression, and we don’t like to have unreachable code.
> On Mar 15, 2019, at 3:09 PM, Brian Goetz wrote:
>
> At the same time, we also reaffirmed o
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "amber-spec-experts" , "Kevin
> Bourrillion"
> Envoyé: Vendredi 15 Mars 2019 23:32:21
> Objet: Re: Updated document on data classes and sealed types
> Yes, if you specify readResolve explicitly, you'll get what you wrote.
> As to "why Serialization b
Yes, if you specify readResolve explicitly, you'll get what you wrote.
As to "why Serialization but not Comparable": because serialization is,
in some very real sense, a language feature (even though it dramatically
pretends to be "just" a library feature) -- and one that has significant
secur
> 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 t
OK, we intend at least one result expression to be required, so the spec
is correct as is.
(I should have been clearer that my belief was about the intent of the
spec, rather than about how I personally think completion should occur.)
Manoj didn't say what javac build he is testing with, but
There is (at least) one area of interaction with other features that I want to
nail down for records: serialization (it’s like death and taxes, always catches
up with you.)
My proposal here is simple: if a record is Serializable, we inject an
implementation of readResolve() that runs back thr
On Mar 13, 2019, at 11:56 AM, Kevin Bourrillion wrote:
>
>- Multi-line-ness and raw-ness are orthogonal concepts.
>
> Is that true, as stated? I would have said that any support for rawness
> automatically gives you support for multi-line-ness by nature, because a
> newline character becom
I think all of this is fine in the context of a multi-line string feature
(option 1a from my mail). I think its highly questionable if we try to apply
this to so-called “raw” string literals, and it becomes a tangled hairball if
the _only_ way to get to the multi-line feature is to randomly sup
At the same time, we also reaffirmed our choice to _not_ allow throw from one
half of a conditional:
int x = foo ? 3 : throw new FooException()
But John has this right — the high order bit is that every expression should
have a defined normal completion, and a type, even if computing sub-ex
On Mar 15, 2019, at 12:01 PM, John Rose wrote:
>
> How do you type "f(throw e)"?
P.S. I suppose this EG has already considered that question,
but here's one answer that occurred to after hitting send:
"throw e" is sugar for an unconstrained poly expression,
approximately:
static
X throwMe(T
On Mar 15, 2019, at 11:39 AM, Alex Buckley wrote:
>
> In a switch expression, I believe it should be legal for every
> `case`/`default` arm to complete abruptly _for a reason other than a break
> with value_.
My reading of Gavin's draft is that he is doing something very
subtle there, which is
On Wed, Mar 13, 2019 at 12:57 PM Brian Goetz wrote:
> To the “indent is good enough” point: Auto reflow is a disaster when
> applied to mixed spaces and tabs; while in general one should avoid this, I
> cannot rule out the possibility that someone might actually want to embed
> such a snippet; in
// The mail below doesn't appear to have made it to the
amber-spec-experts web archive, even though Manoj is a member of the list.
Hey Gavin,
In a switch expression, I believe it should be legal for every
`case`/`default` arm to complete abruptly _for a reason other than a
break with value_.
14 matches
Mail list logo
