The concern is that we need Foo.nestHost == Rational.nestHost and that
the common nestHost includes both Foo and Rational as nestMembers. To
do that, we need to load the nestHost class (if it isn't already).
Getting the interaction between the access check and the additional
class loads right
On Tue, Jun 14, 2022 at 11:29 AM Dan Heidinga wrote:
>
> On Tue, Jun 14, 2022 at 10:19 AM Brian Goetz wrote:
> >
> > It took me a while to understand your concern, but I think I have it now
> > -- it is that we're effectively doing separate access control on LFoo
> > and QFoo. At the language le
Here are two examples of where a B2 class could safely and
beneficially use B2.val:
value class Rational {
Rational[] harmonicSeq(int n) {
Rational.val[] rs = new Rational.val[n];
for (int i=0; irationals could be flat.
> From: "Brian Goetz"
> To: "Remi Forax" , "valhalla-spec-experts"
>
> Cc: "daniel smith" , "valhalla-spec-experts"
>
> Sent: Tuesday, June 14, 2022 3:16:41 PM
> Subject: Re: User model stacking: current status
[...]
>>> Summary:
>>> class B1 { }
>>> value class B2 { private class val { } }
On Tue, Jun 14, 2022 at 10:19 AM Brian Goetz wrote:
>
> It took me a while to understand your concern, but I think I have it now
> -- it is that we're effectively doing separate access control on LFoo
> and QFoo. At the language level this is no problem, but the VM needs a
> story here. Is this
It took me a while to understand your concern, but I think I have it now
-- it is that we're effectively doing separate access control on LFoo
and QFoo. At the language level this is no problem, but the VM needs a
story here. Is this the whole of your concern, or is there more?
- The .val
Overall, I like this proposal. It gives us one new "thing" value
classes, and then some additional rules on exposing the zero (or not)
and right defaults for atomic-ness.
One concern, sketched out below, about using the nest for
accessibility during class loading. Mostly an area where we'll need
And with Rational.val requiring atomic access, we can only flatten it
if the underlying HW supports it (in this case, 2 ints fits nicely in
64bits so we're good). Larger .val's can only be flattened if marked
as "non-atomic" (the B3n case). And because there's no tearing,
handing out the flat
On Tue, Jun 14, 2022 at 9:17 AM Brian Goetz wrote:
>
>
> The val type for B2 should not exist at all
>
>
>
> So B2 is really a B3a whose value projection is encapsulated.
>
>
> and here you lost me, .ref and .val are supposed to be projection types not
> classes, at runtime there is only one clas
The val type for B2 should not exist at all
So B2 is really a B3a whose value projection is encapsulated.
and here you lost me, .ref and .val are supposed to be projection
types not classes, at runtime there is only one class.
And apparently I have to say this again It's fine
> From: "Brian Goetz"
> To: "daniel smith"
> Cc: "valhalla-spec-experts"
> Sent: Tuesday, June 14, 2022 1:04:39 AM
> Subject: Re: User model stacking: current status
> I've done a little more shaking of this tree. It involves keeping the notion
> that the non-identity buckets differ only in the
11 matches
Mail list logo
