Thank you for your answers Walter.
I have not used SAL so I can't tell. It has nonnull
compile-time
tests, and tests of copy or write of the _whole_ span of an
array, that look nice and are missing in D.
I have no idea what that would be 'nice' for, except some
optimizations.<
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). Such long annotations are created
concatenating different pieces almost freely). Then if you by
mistake don't write on all array items (example: because of wrong
for loop intervals, you have missed the last item), you have
introduced a bug. If the static analysis is able to catch this,
you have avoided one bug.
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
wchar_t * wmemcpy(
_Out_writes_all_(count) wchar_t *dest,
_In_reads_(count) const wchar_t *src,
size_t count)
{
size_t i;
for (i = 0; i <= count; i++) { // BUG: off-by-one error
dest[i] = src[i];
}
return dest;
}
Once the LDC2/GDC2 compilers are able to optimize very well
range-heavy D code (currently they are not yet at this level,
this was shown by the recent contest based on the K-Nearest
Neighbour code, where Rust has shown to optimize Range-like code
much better than D for still unknown reasons. The Rust community
has also improved the Rust compiler a bit more on the base of the
results of that benchmark, unlike us) we can avoid many raw loops
in D, and avoid such silly off-by-one errors.
Nor do I think that, in general, such an attribute is
mechanically checkable.<
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.
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.
But I don't believe that at all implies that they are equivalent
in error-proneness.<
OK, and I agree on this.
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.
Bye,
bearophile
