Re: Visual D 1.0.0 released

2020-07-04 Thread Arafel via Digitalmars-d-announce
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

Re: A security review of the D library Crypto

2020-07-01 Thread Arafel via Digitalmars-d-announce
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

Re: DIP1028 - Rationale for accepting as is

2020-05-27 Thread Arafel via Digitalmars-d-announce
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

Re: DIP1028 - Rationale for accepting as is

2020-05-23 Thread Arafel via Digitalmars-d-announce
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

Re: DIP1028 - Rationale for accepting as is

2020-05-23 Thread Arafel via Digitalmars-d-announce
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

Re: DIP1028 - Rationale for accepting as is

2020-05-23 Thread Arafel via Digitalmars-d-announce
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

Re: DIP1028 - Rationale for accepting as is

2020-05-23 Thread Arafel via Digitalmars-d-announce
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

Re: Encouraging preliminary results implementing memcpy in D

2018-06-15 Thread Arafel via Digitalmars-d-announce
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

Re: DIP1004: Inherited Constructors

2016-11-29 Thread Arafel via Digitalmars-d-announce
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