Re: [Vala] Change in 0.23.1 for array ownership and .length parameter

[Tal Hadad <tal_hd hotmail com>]

> What about:
>
> if (foo) {
>    bar = (owned) ar;
> }
> // what now
>
> This behavior is confusing.
It would be unowned, even if in "if" statement, just like I suggest.

Tal

> Date: Tue, 7 Jan 2014 09:24:40 +0100
> From: lethalman88 gmail com
> To: vala-list gnome org
> Subject: Re: [Vala] Change in 0.23.1 for array ownership and .length  parameter
>
> On 07/01/2014 06:46, Tal Hadad wrote:
> > This case trigger me a question I wanted to ask before.
> > Why transforming ownership is nulling the original variable?
> >
> > Instead of nulling, maybe just change variable to behave as unowned.
> >
> > You might say that there is a problem in my solution, like this code:
> >
> > uint8[] ar = new uint8[10];
> > if (some_method() != NULL)
> >      another_method((owned)ar);
> > ...
> >
> > Since after the "if" case, valac can't determinate if ownership was given(at compile time).
> >
> > Despite of this, nulling "ar" variable is even worse in my opinion and it's error prone.
> >
> > The user might use "ar" varible later and it will crush he's application.
> > If he was lucky enough, he would realize that ar is null.
> > It's not easy to find that this line causing it.
> >
> > I suggest solution for the last problem from valac side - treat ar as unowned after the
> > (owned) operator, even if this operator was in "if" block!
> >
> > That way, "ar" won't be null, and the user could use it later only as unowned.
> >
> > And for class/struct fields - I do accept that they must be nulled when transferring ownership.
>
> What about:
>
> if (foo) {
>    bar = (owned) ar;
> }
> // what now
>
> This behavior is confusing.
> _______________________________________________
> vala-list mailing list
> vala-list gnome org
> https://mail.gnome.org/mailman/listinfo/vala-list