On Sat, Jan 4, 2014 at 9:02 PM, Ben Kloosterman <[email protected]> wrote:
> On Sun, Jan 5, 2014 at 12:43 PM, Jonathan S. Shapiro <[email protected]>wrote: > >> On Sat, Jan 4, 2014 at 7:43 PM, Ben Kloosterman <[email protected]>wrote: >> >>> Taking a step back I dont see how life time is becomes an issue just by >>> changing an interface from a reference type to a value type . >>> >> >> Simple. A reference type, ultimately, cannot be stack allocated. It is >> always correct to simply migrate the reference type into the general GC >> heap (i.e. the oldest region). Value types can be stack allocated. Along >> with that comes hard region bounds. >> > > I dont see an issue for the interface being value typed and on the stack > its no diffirent to nay other value type holding a reference. > I think I agree. The only issue is escape, and that's only an issue when the interface references a life-time constrained object. > For interfaces to objects an interface cant outlive an object when the >>> interface holds a "reference" to it . They will always be collected ( >>> whether stack frame , region of GC) together or interface then object. >>> >> >> For an interface to a stack allocated value type, this is not correct. >> > > Yep . I said that later but it doesnt answer the question whether > interfaces should refer to stack allocated value types . What else does > that introduce ? > It introduces a region constraint. Here's why I think we need to look at this. I've been asking when to use interfaces vs. instances. If we use interfaces for I/O, for example, we certainly want to be able to do I/O on value types. And if so, then interface instances need to be able to reference value types, and value types will very often be stack allocated. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
