On 6/17/2014 4:36 PM, bearophile wrote:
If your function is supposed to initialize or modify every item of an array,
with that annotation you can express this semantic fact (with
_Out_writes_all_(s).
Of course, D's 'out' guarantees initialization.
This is an example of code that contains a bug that SAL2 is able to spot:
http://msdn.microsoft.com/en-us/library/hh916383.aspx
The article says a code analysis tool 'could' catch the bug, not that any
actually does. (SAL2 in itself is not a tool.) I suspect that such analysis is
not possible in general, being the halting problem.
we can avoid many raw loops in D, and avoid such
silly off-by-one errors.
By rewriting the loop as:
foreach (i,v; src)
dest[i] = v;
or even:
dest[] = src[];
such silly off-by-one problems disappear. I don't see that SAL2 has much to
offer D, and I think it tries to solve these issues in a clumsy, complex yet
insufficient manner.
I have not used SAL1/SAL2 so I don't know. I know that verifying statically the
SAL annotations takes quite more time than compiling the program. I have read
that SAL is good and it's widely used by Microsoft, and it helps catch and avoid
a large number of bugs for device drivers and similar Windows software. And I
know SAL2 is the second version of this annotation language (so eventual design
mistakes of SAL1 are now fixed, and probably they have removed useless parts), I
know that its designers are intelligent and that Microsoft has some of the best
computer scientists of the world. So I don't know how much SAL2 is able to
statically check the annotations like this one, but I assume in many important
cases SAL2 is able to do it.
I've seen nothing yet that shows SAL2 is inherently superior to D's mechanisms
for avoiding bugs. Microsoft's engineers are undoubtedly smart and competent,
but saying their results are therefore superior is a logical fallacy. Smart and
competent people often devise faster horses rather than inventing cars. (And I'm
no exception.)
The assumption that a .init value is not meaningful is completely arbitrary.<
What I was trying to say is that I think most times you don't want and need to
return a .init, you want to return something different.
That argument applies equally well to all initializations; it is not unique to
'out'. I don't see why 'out' should be special in this regard.
I think the D "out" arguments are a bit a failure, they are rarely used, and I
think returning a tuple (like in Python, Haskell, Go, Rust, etc) is usually
safer and looks cleaner. So I think that once D gets a built-in syntax to manage
tuples well, the usage of out arguments will become even less common.
I agree that tuples may be better.
