On 15/04/2019 21:54, fo...@univ-mlv.fr wrote:
m(List list ) { ... }
...
m(List.of(new Foo(), new Bar()));
Slightly incorrect sir :-)
This is effectively equivalent to the example I wrote earlier
List list = List.of(...)
The expected type will force the equality constraint and will
Most of what i wrote in the L10/L20 memo is accurate :)
> On Apr 15, 2019, at 5:32 PM, fo...@univ-mlv.fr wrote:
>
>
>
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 23:23:57
> Objet: Re: RefObject and ValObject
> V <: V? by value set
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 23:23:57
> Objet: Re: RefObject and ValObject
>> V <: V? by value set inclusion; V? is the type obtained by adjoining `null`
>> to
>> the value set of V.
> Looking for.a better name for this.
The word "reference" is available and fits the bill.
"nullable reference type"
> On Apr 15, 2019, at 2:23 PM, Brian Goetz wrote:
>
>> V <: V? by value set inclusion; V? is the type obtained by adjoining `null`
>> to the value set of V.
>
> Looking for.a better name for this. :”Nullable
> V <: V? by value set inclusion; V? is the type obtained by adjoining `null`
> to the value set of V.
Looking for.a better name for this. :”Nullable value types” is a terrible
name, so I don’t want to say that. (Too confusing with null-default value
types.). They could properly be define
In the document on “Towards a plan for L10 / L20” I tried to answer these, but
I got it slightly wrong. I said:
V <: V? <: ValObject <: Object
But really that should be
V <: V? <: ValObject? <: Object
V <: ValObject <: Object
V <: V? by value set inclusion; V? is the type obtained
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "Maurizio Cimadamore" ,
> "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 22:46:08
> Objet: Re: RefObject and ValObject
>> yes !
>> all generics will suddenly accept value types.
> Yes, this is by design. If you can’t have an ArrayList of
> De: "Maurizio Cimadamore"
> À: "Brian Goetz" , "Remi Forax"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 22:53:49
> Objet: Re: RefObject and ValObject
> I think we should be ok inference-wise, except of course for edge cases (like
> vars) which exposes the guts of the
I think we should be ok inference-wise, except of course for edge cases
(like vars) which exposes the guts of the inference engine.
In normal cases like:
List list = List.of(new Foo(), new Bar())
the equality constraint on the LHS should force a solution which
overrides the new 'RefObject'
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "Maurizio Cimadamore" ,
> "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 22:39:43
> Objet: Re: RefObject and ValObject
>> 1) any codes that has inference
>> var list = List.of(new Foo(), new Bar());
>> will be inferred as List instead of List,
> De: "Maurizio Cimadamore"
> À: "Brian Goetz" , "Remi Forax"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 22:23:25
> Objet: Re: RefObject and ValObject
> Maybe (Remi correct me if I'm wrong), the problem Remi was referring to is
> that
> we also have existing generic
>
> 1) any codes that has inference
>var list = List.of(new Foo(), new Bar());
> will be inferred as List instead of List, so calling a
> method that takes a List will not compile anymore.
Not to dismiss the “what about inference” issue, but any code that combines
`var` with
It's not bikeshedding, hence the "if you prefer ...",
it's trying to explain that it's a typing issue and not a runtime class issue.
Rémi
- Mail original -
> De: "John Rose"
> À: "Remi Forax" , "Maurizio Cimadamore"
>
> Cc: "Brian Goetz" , "valhalla-spec-experts"
>
> Envoyé: Lundi
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "Maurizio Cimadamore" ,
> "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 20:00:52
> Objet: Re: RefObject and ValObject
>> It's not a minor change, and all code that uses a type parameter that have
>> Object as bound will become ambiguous.
> I
That’s right, as we think that will be the best default. Obviously in some
cases users will want to re-bound to .
(For existing code; this comes with compatibility concerns, which we can handle
in various ways. The standard trick to change a bound without changing erasure
is to bound at
Maybe (Remi correct me if I'm wrong), the problem Remi was referring to
is that we also have existing generic declarations like Object> which, in the new world, will mean either VALUE or REFERENCE. I
think this is a consequence of the choice (1) I described in my email -
e.g. reinterpret Object
I think this hangs together very well.
For legacy bytecode (only), the JVM has to be willing to do
these one-time fudges:
- rewrite new java/lang/Object to new java/lang/RefObject
- rewrite invokespecial java/lang/Object.()V to
invokespecial java/lang/RefObject.()V
The verifier can observe
Avoid the Bikeshed! Make sure that temporary or provisional
syntaxes look __Different from permanent ones.
On Apr 15, 2019, at 8:03 AM, Remi Forax wrote:
>
> val, ref and any only applies to Object.
>
> if you prefer in term of notation, let's rename ref Object to Object?, val
> Object to
> De: "Brian Goetz"
> À: "Maurizio Cimadamore"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 17:23:36
> Objet: Re: RefObject and ValObject
>> Your idea of treating Object as abstract is, I believe, a sound one (which
>> doesn't need any extra rule) - but we might have to figure
> For (2) the proposal I saw earlier said something like, we'd like for `new
> Object` to mean REFERENCE. I think that is a siren song, and this issue has
> been addressed by Brian's proposal to deal with `new Object` as a migration
> problem. Rather than suggesting to use some static factory
Please, no.
> On Apr 15, 2019, at 11:03 AM, Remi Forax wrote:
>
>
>
> De: "Brian Goetz"
> À: "Maurizio Cimadamore"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 16:38:58
> Objet: Re: RefObject and ValObject
> Let's model the value vs. reference constraint explicitly - e.g.
>
> Your idea of treating Object as abstract is, I believe, a sound one (which
> doesn't need any extra rule) - but we might have to figure out some story for
> anonymous inner classes of the kind `new Object() { ... }`.
After thinking about it for all of five minutes, I think this may have
> De: "Brian Goetz"
> À: "Maurizio Cimadamore"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 16:38:58
> Objet: Re: RefObject and ValObject
>> Let's model the value vs. reference constraint explicitly - e.g. with 'val'
>> and
>> 'ref' type kinds (and let's not open the can worm
>
> Well, not quite. The choice is between treating 'new Object' specially or
> not. If it's not treated specially there is no new scary type. It's just
> that`new Object` might not have the properties one might hope for (but again,
> those same properties would be lost as soon as you touch
On 15/04/2019 15:38, Brian Goetz wrote:
Let's model the value vs. reference constraint explicitly - e.g. with
'val' and 'ref' type kinds (and let's not open the can worm as to
what the syntax should be, whether it should be a type anno, etc.)
So:
val Object ---> accepts all values
ref
> Let's model the value vs. reference constraint explicitly - e.g. with 'val'
> and 'ref' type kinds (and let's not open the can worm as to what the syntax
> should be, whether it should be a type anno, etc.)
>
> So:
>
> val Object ---> accepts all values
> ref Object ---> accepts all
Mu suggestion here is to leave subtyping on the side, at least for now
and use some other way to describe what's going on.
Let's model the value vs. reference constraint explicitly - e.g. with
'val' and 'ref' type kinds (and let's not open the can worm as to what
the syntax should be, whether
> But the other concerns remain, e.g. as to the fact that the boundary between
> reinterpreted types (Object as RefObject) and non-reinterpreted types (Object
> as top type) seems very fuzzy.
Right, which is why we’re still searching for an answer :)
We really, really want to be able to
- Mail original -
> De: "Maurizio Cimadamore"
> À: "Brian Goetz" , "valhalla-spec-experts"
>
> Envoyé: Lundi 15 Avril 2019 14:20:35
> Objet: Re: RefObject and ValObject
> On 15/04/2019 13:06, Brian Goetz wrote:
>>
>>
>>> But it seems like we have already ruled this out - since, if
>>>
On 15/04/2019 13:06, Brian Goetz wrote:
But it seems like we have already ruled this out - since, if
typeof(new Object()) is 'RefObject', you don't want RefObject <: Object.
I think you misunderstood the "want" here (though it still may not be
possible.)
The desired model is:
- Object
But it seems like we have already ruled this out - since, if
typeof(new Object()) is 'RefObject', you don't want RefObject <: Object.
I think you misunderstood the "want" here (though it still may not be
possible.)
The desired model is:
- Object is the top type. Everything is an
31 matches
Mail list logo
