On Thu, 2014-01-09 at 22:10 +0100, Luca Bruno wrote: > On Thu, Jan 9, 2014 at 9:58 PM, Tal Hadad > <[email protected]> wrote: > > > > That would be a memory leak. > > No it wouldn't: > > If the "if" statement is false, then it should delete it in the end of the > > block. > > > > You might afraid the complicity of valac calculation. > > That could be resolved - using two C variables - one for owned and one for > > unowned. > > The owned always deleted at the end of the block, the trick is that this C > > variable is > > set to null when transferring ownership. > > > > If an owned "bar" was defined outside the block, I already said you're > > right and it > > should be null in when outside the block(e.g. class field), since there's > > no way to > > automate this safely. > > > > I know it may add a minor complicity, but it just seems rational to use an > > object with > > "unowned" access after transferring it to something else, since passing > > ownership > > privilege doesn't means forgetting a reference. > > > > Ok now this makes sense, but it's not worth in my opinion. I've never > encountered such a use case personally. > > > > > > I suppose that most Vala programmer solve this(including me) problem by > > saving > > this variable in different unowned variable, but this is not > > intuitive(especially for a > > new language) and may raise many bugs. > > > > I don't think so, I never had such a use case.
There are a few places in libgee where the code looks like:
unowned G g_ref = g;
something = (owned)g;
do_something_else(g_ref); // This line cannot be moved above
On the other hand I prefer when it blows with segfault during tests
rather then doing potential write to random memory without extra
verbosness:
void do_something(G ref) {
something = null;
}
something = (owned)g; // It's the only reference
do_something_else(g);
g.a += 1; // Oops.
Not mentioning:
if (x) {
something = (owned)g;
}
if (y) {
// It's allowed only if y -> !x [1]
something_else = (owned)g;
}
While it's possible to get around it by Rust-like types but I don't
think it's worth for Vala as it has different goals.
PS. It might be nice on the other hand to extend semantic checker to
catch use-after-ownership-transfer at some point in the future.
[1] For those who don't know implies from logic it's !y || !x or !(y &&
x)
signature.asc
Description: This is a digitally signed message part
_______________________________________________ vala-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/vala-list
