My Language Feature Requests

[Christopher Wright]

Craig Black wrote:
> 
>> It requires you to store a struct by reference. Thus, performance hit.
> 
> No it doesn't.  Structs will be able to be allocated on the stack, 
> without any referencing.  As an OPTION, you will be able to store a 
> struct by reference.  C++ does this very same thing and it is very 
> efficient.

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

A foo (A a) {
    static assert (a.sizeof == 8);
    assert (a.sizeof == 8);
    return a;
}

B b;
b.k = 14;
assert (b.sizeof == 16);
b = foo(b);
assert (b.k == 14); // FAIL


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.

>>> Yes, that will work, but requires a run-time check (and a branch).  
>>> The run-time overhead for what you propose might end up being 
>>> trivial, but I think it could be done at compile-time.
>>
>> I'm not so sure. You'd have to make it undefined behavior to assign a 
>> non-fixed address to a fixed pointer. The reverse is fine, of course.
>>
>> Since class references are pointers, you'd have to have the fixed 
>> storage class apply to them as well. Any reference type, really.
> 
> Yes and all class fields would be fixed as well, unless the class object 
> was instantiated using scope.  This means that when you take the address 
> of them, it results in a fixed pointer.

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?