My Language Feature Requests

[Craig Black]

> Polymorphic structs *have* to be reference types, unless you determine 
> stack layout at runtime. And not only that, you have to modify stack 
> layout after you've created a stack frame. The only saving grace is that 
> you won't have to do that for a stack frame higher than the current one.

Right, but that's not a problem if you disallow polymorphism for stack 
objects.  This is what C++ does and it works very well.  Rather than 
generating a run-time assertion, your code would simply not compile.  If you 
want polymorphism then you have to instantiate then you would have to 
instantiate the struct on the heap.

struct A { int i, j; }
struct B : A { long k; }

A foo (A a) {  return a; }
B b;
b = foo(b); // compile error:  instance of struct B can't be implicitly 
converted to an instance of struct A

Anyway, this is all moot anyway, because I've thought of an easier solution. 
Pointers can be checked at run-time to determine if they address the GC 
heap.  This check could be removed when compiling in release mode, so there 
will be no performance degradation.

So there's no need to dissallow new and delete for classes and we don't need 
struct polymorphism.

>You're saying:
>class Foo {
>    int i;
>}
>
>Foo f = new Foo();
>int* i_ptr = &f.i;
>
>That would be a compile error? f is not fixed; I don't care if the bits in 
>i_ptr change, or the bits in the reference f. Why should I?
>
>Just because I took the address of f.i and stored it in an unfixed pointer, 
>the garbage collector, which has full authority to change the pointer I 
>just got, can't move *f?
>
>Why?

I'm not really sure what you are asking.  If the GC moves the relocates f, 
then i_ptr no longer points the appropriate location.  Isn't that obvious?

Are you suggesting that the GC relocate i_ptr as well?  No GC I know of 
relocates raw pointers, so there's probably a good technical reason why they 
don't.  I'm not a GC expert though.

-Craig