Perhaps there could be the opposite modifier, so the function cannot be called
with nil. Like
Interesting idea but I’d have to think about it more to know if this is a real
problem I’ve ever experienced.
for example, I store some interfaces in a list, and just replaced the
default list with a faster list that assumes all interfaces in the list
are non-nil. (When you know the interface is non-nil, you can replace
the automatic reference counting with a direct call to ._addref, which
is faster. )
But then it crashed because somewhere it was used with a nil interface.
There it would have been useful to mark the new function as only non-nil
accepting, so that it is clear it cannot be used like the old function,
and the compiler have made sure there is no call with nil
Well, as far as the "optional" part goes, the benefits of it will be
fairly limited. Object variables occur in many places, and all of them
can have the nil value, and the compiler has no idea if you did the
check.
You pick a tiny subset of those cases, and attempt to add protection
to it. Given the gain (or rather absence of it, according to the
microscopic size of that subset) the effort (and chance of false
positives) is not worth it.
You would need to have optional or non-nil markers at every variable,
before it becomes really useful.
Benito
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
