Vision for the D language - stabilizing complexity?

[Walter Bright via Digitalmars-d]

On 7/16/2016 5:32 AM, Andrew Godfrey wrote:
> On Saturday, 16 July 2016 at 06:40:31 UTC, Walter Bright wrote:
>
>> But in C++, everything is @system. I'm not sure how people successfully create
>> enormous programs with it.
>
> I work on Microsoft Word. I'm not sure how much I can share about internal
> verification tools, but I can say: We do have SAL annotation:
> https://msdn.microsoft.com/en-us/library/ms235402.aspx

Thanks for taking the time to post about your experience with it. Comparing D 
with SAL is a worthwhile exercise.


> As solutions go, SAL is dissatisfyingly incomplete, and not an easy
> mini-language to learn (I still haven't managed it, I look up what I need on the
> occasions that I need it). But it does impress at times with what it can catch.
> It goes a bit beyond memory safety, too, so I would guess that there are bug
> patterns it can catch that D currently won't.

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.


> One class of bug I find interesting here is uninitialized variables. I'm not
> sure if Visual Studio helps here (we have an internal tool, I know some 3rd
> party tools do this too). But it's interesting that these tools can (often, not
> always) spot code paths where a variable doesn't get initialized. D's approach
> to this helps strongly to avoid using uninitialized memory, but in so doing, it
> discards the information these tools are using to spot such bugs. (So, the kind
> of bug D lets slip through here would tend to be one where variable foo's value
> is foo.init but it should have been initialized to some other value).

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.