I'm in agreement on not adding new contexts but I had the opposite
impression here. Doesn't "having it do range checking" require a new
context as this is different from what assignment contexts allow
today? Or is it the case that regular, non-match assignment must be
total with no left over that allows them to use the same context
despite not being able to do the dynamic range check? As this
sentence shows, I'm confused on how dynamic range checking fits in the
existing assignment context.
Or are we suggesting that assignment allows:
byte b = new Long(5);
to succeed if we can unbox + meet the dynamic range check? I'm
clearly confused here.
At a meta level, the alignment target is:
- given a target type `T`
- given an expression `e : E`
then:
- being able to statically determine whether `T t` matches `e` should
be equivalent to whether the assignment `T t = e` is valid under the
existing 5.2 rules.
That is to say, the existing 5.2 rules may look like a bag of ad-hoc,
two-for-one-on-tuesday rules, but really, they will be revealed to be
the set of conversions that are consistent with statically determining
whether `T t` matches `e : E`. Most of these rules involve only T and E
(e.g., widening primitive conversion), but one of them is about ranges,
which we can only statically assess when `e` is a constant.
Conversions like unboxing or casting are burdened by the fact that they
have to be total, which means the "does it fit" / "if so, do it" / "if
not, do something else (truncate, throw, etc)" all have to be crammed
into a single operation. What pattern matching is extracts the "does it
fit, and if so do it" into a more primitive operation, from which other
operations can be composed.
Is it accurate to say this is less reusing assignment context and more
completely replacing it with a new pattern context from which
assignment can be built on top of?
Yes! Ideally, this is one of those "jack up the house and provide a
solid foundation" moves.
At some level, what I'm proposing is all spec-shuffling; we'll either
say "a widening primitive conversion is allowed in assignment context",
or we'll say that primitive `P p` matches any primitive type Q that can
be widened to P. We'll end up with a similar number of rules, but we
might be able to "shake the box" to make them settle to a lower energy
state, and be able to define (whether we explicitly do so or not)
assignment context to support "all the cases where the LHS, viewed as a
type pattern, are exhaustive on the RHS, potentially with remainder, and
throws if remainder is encountered." (That's what unboxing does; throws
when remainder is encountered.)
Ok. So maybe I'm not confused. We'd allow the `byte b = new Long(5);`
code to compile and throw not only on a failed unbox, but also on a
dynamic range check failure.
No ;)
Today, we would disallow this assignment because it is not an unboxing
followed by a primitive widening. (The opposite, long l = new Byte(3),
would be allowed today, except that we took away these constructors so
you have to use valueOf.) We would only allow a narrowing if the RHS
were a constant, like "5", in which case the compiler would statically
evaluate the range check and narrow 5 to byte.
Tomorrow, the assignment would be the same; assignment works based on
"statically determined to match", and we can only statically determine
the range check if we know the target value, i.e., its a constant. But,
if you *asked*, then you can get a dynamic range check:
if (anInt matches byte b) // we get a range check here
The reason we don't do that with assignment is we don't know what to do
if it doesn't match. But if its in a conditional context (if or
switch), then the programmer is going to tell us what to do if it
doesn't match.
If we took this "dynamic hook" behaviour to the limit, what other new
capabilities does it unlock? Is this the place to connect other
user-supplied conversion operations as well? Maybe I'm running too
far with this idea but it seems like this could be laying the
groundwork for other interesting behaviours. Am I way off in the
weeds here?
Not entirely in the weeds. The problem with assignment, casting, and
all of those things is that they have to be total; when you say "x = y"
then the guarantee is that *something* got assigned to x. Now, we are
already cheating a bit, because `x = y` allows unboxing, and unboxing
can throw. (Sounds like remainder rejection!) Now, imagine we had an
"assign or else" construct (with static types A and B):
a := (b, e)
then this would mean
if (b matches A aa)
a = aa
else
a = e // and maybe e is really a function of b
In the case of unboxing conversions, our existing assignment works kind
of like:
a := (b, throw new NPE)
because we'd try to match, and if it fails, evaluate the second
component, which throws.
Obviously I'm not suggesting we tinker with assignment in this way, but
the point is: pattern matching gives you a chance to stop and say:
"don't do it yet, but if you did it, would it work?"
Intuitively, the behaviour you propose is kind of what we want - all
the possible byte cases end up in the byte case and we don't need to
adapt the long case to handle those that would have fit in a byte.
I'm slightly concerned that this changes Java's historical approach
and may lead to surprises when refactoring existing code that treats
unbox(Long) one way and unbox(Short) another. Will users be confused
when the unbox(Long) in the short right range ends up in a case that
was only intended for unbox(Short)? I'm having a hard time finding an
example that would trip on this but my lack of imagination isn't
definitive =)
I'm worried about this too. We examined it briefly, and ran away, when
we were thinking about constant patterns, specifically:
Object o = ...
switch (o) {
case 0: ...
default: ...
}
What would this mean? What I wouldn't want it to mean is "match Long 0,
Integer 0, Short 0, Byte 0, Character 0"; that feels like it is over the
line for "magic". (Note that this is about defining what the _constant
pattern_ means, not the primitive type pattern.) I think its probably
reasonable to say this is a type error; 0 is applicable to primitive
numerics and their boxes, but not to Number or Object. I think that is
consistent with what I'm suggesting about primitive type patterns, but
I'd have to think about it more.
Object o =...
switch(o) {
case (long)0: ... // can we say this? Probably not
case long l && l == 0: // otherwise this would become the way to
catch most of the constant 0 cases
default: ....
}
I'm starting to think the constant pattern will feel less like magic
once the dynamic range checking becomes commonplace.
Probably can't say `case (long) 0`, but you can say `case 0L`. Though we
don't have suffixes for all the types.
One reason this is especially undesirable is that one of the forms of
let-bind is a let-bind *expression*:
let P = p, Q = q
in <expression>
which is useful for pulling out subexpressions and binding them to a
variable, but for which the scope of that variable is limited. If
refactoring from:
Possible typo in the example. Attempted to fix:
int x = stuff;
m(f(x));
to
m(let x = stuff in f(x))
// x no longer in scope here
Not sure I follow this example. I'm not sure why introducing a new
variable in this scope is useful.
Two reasons: narrower scope for locals, and turning statements into
expressions.
A common expression with redundant subexpressions is "last 3 characters
of string":
last3 = s.substring(s.length() - 3, s.length())
We can refactor to
int sLen = s.length();
last3 = s.substring(sLen - 3, sLen);
but some people dislike this because now the rest of the scope is
"polluted" with a garbage variable. A let expression narrows the scope
of sLen:
last3 = let sLen = s.length()
in s.substring(sLen - 3, sLen);
This becomes more important when we want to use the result in, say, a
method call; now we have to unroll the declaration of any helper
statements (e.g., `int sLen = s.length()`) to outside the method call.
A similar thing happens when we want to create an object, mutate it, and
return it; this often requires statements, but a let expression turns it
back into an expression.
