Relaxed assignment conversions for sealed types

[Brian Goetz]

>>    But, the part of this that is worth discussing is that yes, this could be a _conversion_
>> rather than assignability.  The effect of this would mostly show up in
>> overload selection (where the strongly applicable options are preferred
>> over the loosely ones) and type inference. Its a possibility, but I'm
>> not sure it really buys much, and doesn't really address Tagir's "too
>> magic" concerns.  (If anything, conversions are more magic than
>> assignability.)
> I've proposed boxing because i fear that if subtyping and this new conversion are at the same level, we will have trouble with inference because you can go in both direction at the same time.
>

Sure, it's a reasonable thing to consider.  But I worry also we're 
getting lost in the details of _how_, and the more important 
conversation right now is the "what language are we building" one. We 
know we have a construct that (a) has the seeds of better type checking 
in it, and (b) will tempt people to do things that are not as type safe 
as we can make them.  I'm skeptical that "do nothing" here is the right 
move.

Since I still can't avoid having a paint at the bikeshed, I'll point out 
that a sneaky vector by which we could address this is to lean on our 
new friend, pattern totality.  Suppose we have:

     sealed abstract class C permits D { }
     final class D extends C { }

We have already said that the type pattern `D d` is total on C (with 
some remainder.)  We're already considering pattern assignment for total 
patterns.  For example, if Foo(...) is a deconstruction pattern on Foo, 
then the following:

     Foo(var x, var y) = aFoo;

would be a valid statement, it would deconstruct the RHS, bind variables 
x and y, and throw on the remainder (which in this case includes null.)  
Now, note that

     D d = c;

could be interpreted as a local variable declaration, _or_ as a pattern 
match if the type pattern `D d` is total on C with some remainder.  (It 
is no accident that a type pattern and a variable declaration look alike.)

Now, one could reasonably object that this might be a clever pun, but 
that the users won't get the joke, since it does look so much like an 
assignment.  In the past, we had toyed with giving this statement some 
more obvious syntax, like:

     let D d = c;

but over time this felt more and more like a Stroustrup's Rule artifact 
(new syntax should LOOK DIFFERENT!)  Further, we'd like to have a path 
to using patterns in things like method declarations:

     void foo(Point(var x, var y) p) { ... x, y, and p are all bound 
here... }

which is a pretty natural way to use total patterns (once users are 
ready for this, they surely are not now.)  Requring that 
unconditional-bind be a statement ("let") rather than something more 
fluid puts roadblocks to getting there.

So, to summarize, another vector by which we could get there is to say that

     D d = c;

is a pattern match of a total pattern (D d) on the operand c.  This 
would mean we could do this assignment for locals, but wouldn't do 
anything for us in method invocation context.  That doesn't sound 
immediately better, but its a direction to consider.

But, in general: let's try to converge on the goals before we dive too 
deep into details.