**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
