Beta 2.072.0-b2

[Sönke Ludwig via Digitalmars-d-announce]

Am 10.10.2016 um 12:45 schrieb Sönke Ludwig:
> Am 10.10.2016 um 12:20 schrieb Martin Nowak:
>> On Monday, 10 October 2016 at 09:03:53 UTC, Sönke Ludwig wrote:
>>> Of course, the new error is more restrictive than it should be, namely
>>> if the uninitialized pointer field gets written before the first read,
>>> it would still be safe.
>>
>> That's surprising b/c void initializers for struct fields didn't use to
>> work.
>
> Hm, thanks for the hint - if that's still the case, that leads to the
> very simple workaround of simply removing the "= void". Would have been
> nice in theory to have real void initialization of course, plus it was
> there for working around that (fixed?) issue with slow compilation times
> for large static arrays, but there is probably no real reason now to
> keep it.
>
>> I need to research the intent behind this to say sth. detailed, though
>> usually an shouldn't break working code, only deprecate it.
>

Okay, I stumbled over another occurrence of this:

Bugzilla 16195: delete should be @system
   <- This makes it impossible to use `scope` variables in @safe scopes. 
The whole scope/function needs to be marked trusted now.

Bugzilla 14496: void initialization of member with indirections must not 
be @safe
   <- This makes it impossible to use std.typecons.scoped as an 
alternative, because it requires void initialization due to its disabled 
default constructor, or it would again affect the @safety of the whole 
surrounding scope.

I think both need to be adjusted to use a deprecation warning instead of 
an error. But the first one in conjunction with `scope` variables should 
be legal anyway, as long as the variable doesn't leave the scope (e.g. 
DIP1000). Maybe it makes sense to lower this to "scope (exit) () 
@trusted { delete var; } ();" instead of "scope (exit) delete var;" for 
now (making sure that the stack allocation optimization still works).