[This is just a rambing e-mail outlining some problems I'm running
into. Though I am stressing these problems to make sure they are not
glossed over, I'm *not* suggesting we give up aliases or anything like
that.]
The issue I'm running into is that obj types*, function types, and
type parameters are 'opaque' and, as such, can contain everything.
This means that any boxed value returned from a function that took a
stateful obj, parameterized type, or function type (or something that
contains one!) must be suspected of being reachable from that object.
This means that very typical code, for example stuff passing a context
around where the context contains a hash table or other state obj has
a problem. If we go with function parameter aliasing solution #2 (not
allowed to pass aliasing things) then any function in such a
context-passing module that takes both a context and an alias, can not
be called on any boxed (or box-containing) value that was returned
from another context-taking function. This seems like it'll invalidate
a serious percentage of the code in the current compiler, with no
obvious way to 'fix' it.
Going with solution #1 (you may pass aliasing aliases to functions)
instead, we'd be in a situation where an obj or parameterized argument
may alias with every alias passed in, which means that after passing
said obj or parameterized argument to any function you can no longer
be sure your alias is still valid. This is worse than the situation
described above.
A 'distinguish' operation would provide a way out, but if I understand
what you're proposing correctly it'll traverse the values at run-time.
Proving two big (maybe even cyclic) data structures don't share
structure is an arbitrarily expensive operation. Sprinkling these in
your code will probably cause a noticeable slowdown. On top of that,
while a run-time failure is better than memory corruption, it's not
*much* better — passing in an alias is something that is easy to do
accidentally, in a way that only occurs in corner cases, meaning we'd
be putting hard-to-test land mines in our code. (For this reason,
inserting them implicitly is probably a really bad idea.)
So yeah, those are the issues I see. Discuss.
(Seems we're once again entering uncharted territory. As with the
effects system, that's always dangerous.)
*) Here I mean types defined like 'type foo = obj { ... }' rather than
'obj foo() { ... }'. I saw someone claiming the former syntax was
invalid in the IRC logs this week (it's not), so maybe the distinction
is not widely understood.
Best,
Marijn
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
