[bitc-dev] Revisiting stack-ref

[Jonathan S. Shapiro]

On Mon, 2007-06-04 at 16:26 +0100, Sam Mason wrote:

> I've just noticed a problem with these by-references values though.
> That of calling a "by-reference" method with the reference to an element
> of a union and changing the tag of the union invalidating the type of
> the element inside the "by-reference" function.  I can only think of
> very contrived bits of code that would trigger it, but it would break
> type safety.

Yes. The issue is similar to the INNER-REF construct we have been
considering. The item passed must not reside within a union leg. It is
legal to pass an object of union type, but there is no "union leg type".
That would require dependent types, which we don't currently do.

> yes, which is why (I believe) references got added to C++.  I've never
> seen a way to do this safely without some heavy type-level stuff, like
> alias types.  This is a big step from what you've got at the moment
> though.

References were added too late in C++. For example: the "this pointer"
should have been a "this reference".

The problem in C++ isn't the introduction of C++ reference types (i.e.
T&). It's (a) the ability to take their address, (b) the general
non-safety around union legs, and (c) the ability to capture them. It is
possible to get some spectacularly bad liveness violations when a class
has a member field of reference type.

> > I do think it is better than "copy on closure formation", which appears
> > to be what the Felix folks are considering.
> 
> I don't know Felix at all.  I've had a look through the language
> reference[1] on their website but can't seem to find anything about
> this.

I was poking through their wiki, and it showed up on a blog. It's an
open design issue.

The current Felix performance results are actually pretty impressive.


shap