Vision for the D language - stabilizing complexity?

[Andrew Godfrey via Digitalmars-d]

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.