Attendees: Remi, Simms, Brian, John, Fred, DanS, Tobi, DanH
- Brian: So there is Fred's proposal for translation strategy for cast
(using the whole envelop and treat Q sig as not-null)
- DanH: yeah we need to look at how legacy would work
- Brian: So Q types didn't exist before, old files assume L
- John: A little concern about "L-type" envelopes appearing there
too...need to read the full email...
- Remi: why was this a probably ?
- Brian: because `checkcast` with `null` on TOS will let it pass for
Q-types, it won't look any for further if `null`
- John: think of if as null-check gate for Q-type sig
- DanH: so does that mean we need to pre-load at its appearance ?
- John: not necessarily
- Brian: pretty sure Fred left that blank on purpose
- Read through, look at impl, debate on list
- Fred: Summary for `checkcast`:
- ("Hey `null`") "are you are part of the value set of this type ?"
- Simms: so the "preload" question, is that for list debate ?
- Fred: well we don't preload for `ldc` etc so...
- Debate follows whereby the "note taker" was far too interested in
talking
- There is an argument to say we have limited "pre-loading" for
specific feature enablement...
- ...if `checkcast` hitting `null` TOS and throwing `CCE` is not
preformant anyway, extra load won't matter...not common
- if `checkcast` not `null` TOS, type needs resolving anyway
- ...
- John: do we need to be explicit about this in the spec
- DanH: we want to be explicit
- Remi: agreed
- Debate Summary: All operations naming Q-type, must load, so
`instanceof` and `checkcast`
- Simms: so the design space is narrowing, I owe an email listing
remaining items, will appreciate if anything is missing, or if there are
concerns to name them...
- ...would prefer to move on to longer GS design discussion
- also inline types seem close, and still "simple to use" (further
features would be hard to motivate)
- Brian: also owe an email on specialization
