On 4/7/20 15:00, Rainer Schuetze wrote:
Hello,
after having passed the 10 year anniversary of public availability
recently, it is finally time to release version 1.0 of Visual D, the
Visual Studio extension that adds D language support to VS 2008-2019.
You can find the installer at
http://raine
On 1/7/20 9:19, Cym13 wrote:
As some of you may know one of my hobbies is to review open source
software for security issues. About a year ago I reviewed the RSA
implementation of Crypto[1]: a native D library which, according to dub
statistics, is fairly popular.
Issues were found and after
On 27/5/20 11:50, Walter Bright wrote:
It is a fair point. But I am looking a bit farther than that - the team
that is responsible for QAing software (sometimes it is a separate
team). The QA team cannot tell the difference between correctly
annotated @trusted code and greenwashed code.
T
On 24/5/20 5:28, Walter Bright wrote:
I'd like to emphasize:
1. It is not possible for the compiler to check any declarations where
the implementation is not available. Not in D, not in any language.
Declaring a declaration safe does not make it safe.
Here, I agree with Timon: only @system
On 24/5/20 0:38, ag0aep6g wrote:
On 24.05.20 00:17, Arafel wrote:
On 24/5/20 0:02, ag0aep6g wrote:
... and @system static constructors and `--boundscheck=off` and
initializers of globals
Other than `--boundscheck=off`, that is presumably actively chosen by
the user (as is @trust), would th
On 24/5/20 0:02, ag0aep6g wrote:
... and @system static constructors and `--boundscheck=off` and
initializers of globals
Other than `--boundscheck=off`, that is presumably actively chosen by
the user (as is @trust), would the others be allowed without `@trusted`
in otherwise 100% @safe code
On 23/5/20 20:40, Johannes T wrote:
On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
I have made these points before, but I'll summarize them here
for convenient referral.
[..]
Thank you for the detailed and insightful explanation.
Would it be feasible to have a follow-up DIP that
Well, e-mail was never meant to be reliable or secure... BTW, there are
already solutions to prevent impersonation: sign the messages with
either PGP or S/MIME... the former is more decentralised, and the later
usually comes together with stronger verifications, like personal
identification of
On Monday, 28 November 2016 at 02:38:00 UTC, Dicebot wrote:
DIP 1004 is merged to the queue and open for public informal
feedback.
PR: https://github.com/dlang/DIPs/pull/42
Initial merged document:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1004.md
If you want the change to be approv