> On Jul 1, 2021, at 5:48 AM, Brian Goetz wrote:
>
>
>>
>> Which reminds me: I think we should
>> allow calls to methods on `this` inside a
>> constructor. (Do we?) A clean way to
>> statically exclude incomplete values of `this`
>> would be to outlaw such self-calls until all
>> final fie
I sincerely claim that your statement is in the same boat. You're
speaking of what has /happened/ to be the case in Java, because reasons.
However, I think the /concept/ of null is more basic; it is just
"there is no instance here". Try to do instance stuff, blow up always,
that's null.
Which reminds me: I think we should
allow calls to methods on `this` inside a
constructor. (Do we?) A clean way to
statically exclude incomplete values of `this`
would be to outlaw such self-calls until all
final fields are definitely assigned. The
current language (for identity classes)
c
On Jun 29, 2021, at 2:36 PM, Kevin Bourrillion
mailto:kev...@google.com>> wrote:
Speaking of orthogonality, there *is* an open question about how we interpret
, and this is orthogonal to the question of whether should
be the "default default". We've talked about:
- It's interchangeable with n
On Wed, Jun 30, 2021 at 8:40 AM Brian Goetz wrote:
Of your points, I think this is the controversial one, and it goes straight
> to "what is the point of primitive classes."
>
> You kind of dismiss optimization, but of course a big part of the point is
> classes that are more optimizable; if we d
P.S. Wikipedia gives for boojum: “A fictional
animal species in Lewis Carroll's nonsense
poem The Hunting of the Snark; a particularly
dangerous kind of snark.”
“But if ever I meet with a Boojum, that day,
In a moment (of this I am sure),
I shall softly and suddenly vanish away—
And the not
> On Jun 30, 2021, at 8:39 AM, Brian Goetz wrote:
>
> Now, let's talk more about null. Null is a *reference* that refers to no
> object. For a flattened/direct object (P.val), null cannot be in the value
> set (it's the wrong "kind"), though we can arrange for a primitive to behave
> like n
Of your points, I think this is the controversial one, and it goes
straight to "what is the point of primitive classes."
You kind of dismiss optimization, but of course a big part of the point
is classes that are more optimizable; if we didn't care about
optimization, we wouldn't bother with p
Thanks for giving this your attention!
On Tue, Jun 29, 2021 at 12:56 PM Dan Smith wrote:
E.g., I can imagine a world in which a no-good-default primitive class is
> no better than an identity class in most use cases, and at that point,
> we're best off simply not supporting the no-good-default f
> On Jun 29, 2021, at 11:54 AM, Kevin Bourrillion wrote:
>
> Sorry for quietness of late.
Glad to have you back!
Unfortunately, there's not much new to report in this area, other than the fact
that we are aware that more design and prototyping work is needed.
Here's an open task to prototype
Sorry for quietness of late.
Some new thoughts.
- Default behaviors of language features should be based *first* on
bug-proof-ness; if a user has to opt into safety that means they were not
safe.
- `null` and nullable types are a very good thing for safety; NPE
protects us from mor
Let me propose another strategy for Bucket 3. It could be implemented
at either the VM or language level, but the latter probably needs some
help from the VM anyway. The idea is that the default value is
_indistinguishable from null_. Strawman:
- Classes can be marked as default-hostile (e
Picking this issue up again. To summarize Dan's buckets:
Bucket 1 -- the zero default is in the domain, and is a sensible default
value. Zero for numerics, empty optionals.
Bucket 2 -- there is a sensible default value, but all-zero-bits isn't it.
Bucket 3 -- there simply is no sensible defa
> On Aug 5, 2020, at 2:11 AM, Peter Levart wrote:
>
>
> On 8/5/20 10:05 AM, Peter Levart wrote:
>> Javac could emit a check before accessing a field from code where embedded
>> check is not performed (where instance is not "this") and before invoking
>> default interface method (as determine
On 8/5/20 10:05 AM, Peter Levart wrote:
Javac could emit a check before accessing a field from code where
embedded check is not performed (where instance is not "this") and
before invoking default interface method (as determined by static type)
...hm, javac could not do that, right? It does
On 8/3/20 10:21 PM, Dan Smith wrote:
On Aug 2, 2020, at 10:08 AM, Peter Levart wrote:
In either case I think it is a matter of the inline class bytecode and not the
code doing invocation (the call site). So it is safe by itself. Or am I missing
something?
You're describing Option F. Yes, w
> On Aug 2, 2020, at 10:08 AM, Peter Levart wrote:
>
> In either case I think it is a matter of the inline class bytecode and not
> the code doing invocation (the call site). So it is safe by itself. Or am I
> missing something?
You're describing Option F. Yes, we can have javac generate check
Hi,
On 7/28/20 9:06 PM, Brian Goetz wrote:
I think what we need for Bucket 3 (which I think we agree is more
important than Bucket 2) is to (optionally, only for NGD inline
classes) restore parity with reference types by ensuring that the
receiver of a method invocation is never seen to be the
> On Jul 28, 2020, at 11:33 AM, Tobi Ajila wrote:
>
> > Bucket #3 classes must be reference-default, and fields/arrays of their
> > inline type are illegal outside of the declaring class. The declaring class
> > can provide a flat array factory if it wants to. (A new idea from Tobi,
> > he'll
I think it would help if we had a clear sense as to what proportion of
inline-types we think will have this "bad default" problem. Last year
when we discussed null-default inline types the thinking was that
about 75% of the motivation for null-defaults was migrating VBC, 20%
for security, 5%
: Dan Smith
> To: valhalla-spec-experts
> Cc: Brian Goetz
> Date: 2020/07/21 02:41 PM
> Subject: [EXTERNAL] Re: Revisiting default values
> Sent by: "valhalla-spec-experts"
>
>
> > On Jul 20, 2020, at 10:27 AM, Brian Goetz
wrote:
> >
> > That said,
> On Jul 20, 2020, at 10:27 AM, Brian Goetz wrote:
>
> That said, doing so in the language is potentially more viable. It would
> mean, for classes that opt into this treatment:
>
> - Ensuring that `C.default` evaluates to the right thing
> - Preventing `this` from escaping the constructor
Responding to Kevin's tangent:
- Of the one's on Dan's list, one could argue that even some of the
ones in Bucket 1 are questionable, such as `char` or `Instant`. The
ones that really seem like slam dunks are: numerics (int, long, etc),
boolean, and maybe Optional. That's a small list.
(A
So the default value may a valid value or may be an invalid value,
if it's an invalid value it should be the author of the class that say that
because in Java we prefer declaration site to use site.
One way is to try to teach the VM how to do the conversions, i want to explore
another way where
> On Jul 14, 2020, at 6:39 AM, Peter Levart wrote:
>
> What about a variant of G or J where an inline class would designate a single
> field to be used for "isDefault" checks. Instead of comparing all fields for
> "zero" value, a single designated field would be used in checks. So a class
> is
What about a variant of G or J where an inline class would designate a
single field to be used for "isDefault" checks. Instead of comparing all
fields for "zero" value, a single designated field would be used in
checks. So a class is free to choose which of the existing fields is
"never zero/nu
> On Jul 13, 2020, at 12:19 PM, Dan Smith wrote:
>
>> On Jul 10, 2020, at 12:23 PM, Dan Smith wrote:
>>
>> Option G: JVM support for default instance guards
>>
>> Inline class files can indicate that their default instance is invalid. All
>> attempts to operate on that instance (via field/
> On Jul 10, 2020, at 12:23 PM, Dan Smith wrote:
>
> Option G: JVM support for default instance guards
>
> Inline class files can indicate that their default instance is invalid. All
> attempts to operate on that instance (via field/method accesses, other than
> 'withfield') result in an excep
From valhalla-spec-observers:
> On Jul 12, 2020, at 10:45 PM, Zheka Kozlov wrote:
>
> Sorry for a probably stupid question but aren't all classes from Bucket #2
> and #3 ref-default? Which means when we are calling new LocalDate[10], all
> elements of the array are initialized to null. And sin
> On Jul 10, 2020, at 12:46 PM, Kevin Bourrillion wrote:
>
> My reason for complaining here is not just about the java.time types
> themselves, but to argue that this is an important 4th bucket we should be
> concerned about. In some ways it is a bigger problem that Bucket #3 "no good
> defaul
30 matches
Mail list logo
