Hi Louis —
I think there are a few options here (and probably others that the experts
could suggest... in this case, I'm mostly a messenger who's just trying
these features out for the first time today as well, so still picking up
some tricks as I go).
First an assumption: I take it that `recycleList.remove(n)` is going to
store the thing that's removed in `n`? (i.e., `n = recycleList.remove();`
might be another way to express it showing the assignment?)
The first way to write this pattern that occurs to me is as follows, where
I'm going to take the above liberty with reframing the recycleList API:
proc recycle(): unmanaged object {
try {
return recycleList.remove();
} catch exception {
return new unmanaged object();
}
}
Here, both branches return a non-nilable unmanaged object (assuming
remove() does when it doesn't throw), so things are fine.
Another way would be to use the '!' operator (and here I'll revert to the
original API to avoid cheating):
proc recycle(): unmanaged object {
var n: unmanaged object?; // this needs to use ? since n will
// initially be nil
try {
recycleList.remove(n);
} catch exception {
n = new unmanaged object();
}
return n!; // will halt if 'n' is nil, but you've assured me it won't
}
Note, however, that if the try block throws an exception that doesn't
match your exception pattern, 'n' will be 'nil' and the ! operator will
fail.
I think a third approach would be to cast 'n' to 'unmanaged object', but
I'm not as expert at that approach yet (casting nilability away throws
when the value is 'nil' whereas '!' halts).
To your larger point, though, I think you're correct that nilability can't
be proven correct by a compiler in all cases (I suspect its equivalent to
the halting problem), so we do what compilers typically do: Be
conservative when we can't be sure and rely on the user to help out in
such cases.
That said, note that checking nilability in Chapel is more about making
sure that you don't assign a `nil` or a `C?` to a `C` without first doing
something to convert it safely (like the '!' operator or a cast). And
less about trying to infer whether something is assigned non-nil values
along all paths or not.
-Brad
On Sat, 24 Aug 2019, Louis Jenkins wrote:
**Memory/Object Pool Pattern**
If I know for a fact that a function will always return an object that
is not nil, such as the case of an object pool that will create a new
object if an object cannot be recycled, how do you represent this with
the new changes? It seems that the compiler cannot be determine if the
nil-ability of an object can be proven statically, such as the case in
the below code snippet; the compiler _could_ see that, in any and all
paths, it is impossible for `n` to be `nil`, and is therefore not
nil-able; a lot of static analyzers are capable of performing such
analysis as well. Would this be considered something 'impossible' to do
from a design standpoint, or would this be something that is planned to
be supported? If not, how do you prevent nil-ability tainting
everything? Is it planned to be able to say to the compiler: "I know
that this is not nil-able after this point, please stop interfering with
my code?" - I kid, I kid, but really, is there a way to tell it that
something is non-nilable after a point?
"""
use List;
var recycleList : list(unmanaged object);
proc recycle() : unmanaged object {
var n : unmanaged object; // ???
try {
recycleList.remove(n);
} catch exception {
n = new unmanaged object();
}
return n;
}
var x = recycle();
writeln(x);
"""
On 8/23/19, 8:20 PM, "Brad Chamberlain" <[email protected]> wrote:
I'll answer the parts of this I remember the answers to offhand and leave
the rest for others:
> What would an array of `var A : [D] C` contain by default?
This would be an error (assuming a semicolon after the 'C' rather than an
`= ...`, as would `var A: C;` However, I believe at present, the compiler
only checks the latter, not the former (i.e., there's still a TODO here).
> Why not make all types nil-able by default and make nil-ability an
> opt-in feature?
That is a potential consideration for the future (but is not considered a
breaking change since no other types are currently nilable).
-Brad
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
