Re: Beta 2.072.0-b2
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).
Re: Beta 2.072.0-b2
On Monday, 10 October 2016 at 10:45:37 UTC, Sönke Ludwig wrote: 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. Here is the ER for using `= void` field initializers. [Issue 11331 – Inefficient initialization of struct with members = void](https://issues.dlang.org/show_bug.cgi?id=11331)
Re: Beta 2.072.0-b2
On Sunday, 9 October 2016 at 22:01:31 UTC, Martin Nowak wrote: On Sunday, 9 October 2016 at 14:36:49 UTC, Dicebot wrote: Which branch changelog content is generated from? Stable, the changelog is also included in the docs that are in the packages. I do merge stable back into master to publish them though. I am confused in that case. What shall I do to replace http://dlang.org/changelog/2.072.0.html#dash_safe with my changes from https://github.com/dlang/dmd/blob/stable/changelog.dd ?
Re: Beta 2.072.0-b2
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.
Re: Beta 2.072.0-b2
On 10/10/2016 12:28 PM, Martin Nowak wrote: It's on our heap and will be addressed soon. Please look at our trello board. https://trello.com/b/XoFjxiqG/active These two 2.072 regressions seem to be missing from Trello: https://issues.dlang.org/show_bug.cgi?id=16013 https://issues.dlang.org/show_bug.cgi?id=16273
Re: Beta 2.072.0-b2
On Monday, 10 October 2016 at 10:06:25 UTC, Basile B. wrote: Any news on the front of https://issues.dlang.org/show_bug.cgi?id=16574 ? It's on our heap and will be addressed soon. Please look at our trello board. https://trello.com/b/XoFjxiqG/active
Re: Beta 2.072.0-b2
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. I need to research the intent behind this to say sth. detailed, though usually an shouldn't break working code, only deprecate it.
Re: Beta 2.072.0-b2
There is an error [1] (caused by [2]) in taggedalgebraic, because void initializers for pointer types are now invalid in safe code. The question now is, is there any workaround that can be done in the library, or will every library user have to fix this? 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. [1]: https://github.com/s-ludwig/taggedalgebraic/blob/2d9f9c537f9616bbe2a7072a9aa42ff1fd95f6d6/source/taggedalgebraic.d#L280 [2]: https://github.com/s-ludwig/taggedalgebraic/blob/2d9f9c537f9616bbe2a7072a9aa42ff1fd95f6d6/source/taggedalgebraic.d#L56
Re: Beta 2.072.0-b2
On Sunday, 9 October 2016 at 14:36:49 UTC, Dicebot wrote: Which branch changelog content is generated from? Stable, the changelog is also included in the docs that are in the packages. I do merge stable back into master to publish them though.
Re: Beta 2.072.0-b2
Which branch changelog content is generated from?
