On Saturday, 16 July 2016 at 21:52:02 UTC, Walter Bright wrote:
On 7/16/2016 5:32 AM, Andrew Godfrey wrote:
[...]
Thanks for taking the time to post about your experience with
it. Comparing D with SAL is a worthwhile exercise.
[...]
I've seen SAL before, but have not studied it. My impression is
it is much more complex than necessary. For example,
https://msdn.microsoft.com/en-us/library/hh916383.aspx
describes annotations to memcpy(). I believe these are better
handled by use of dynamic arrays and transitive const. But
there's no doubt that careful use of SAL will reduce bugs.
[...]
Uninitialized variables, along with their cousin adding a field
to a struct and forgetting to initialize it in one of its
constructors, have caused me endless problems and cost me
untold hours. It was a major motivator to solve this problem in
D, and I am pleased that my problems with it have been
essentially eliminated.
You write that SAL still leaves undetected cases of
uninitialized variables. I think I'd rather live with the
limitation you mentioned in the D way rather than risk
uninitialized variables. Having a predictable wrong value in a
variable is debuggable, having an unpredictable wrong value is
often not debuggable, which is why they consume so much time.
I'm not trying to argue against D's design here. I'm thinking:
1) Static analysis tools still have relevance even in D code.
2) I wonder if an "uninitialized" feature would be worthwhile.
That is, a value you can initialize a variable to, equal to
'init', but that static analyzers know you don't mean to ever use.
