On 1/2/2020 9:06 AM, Guillaume Piolat wrote:
> - Never needed memory-safety, don't see the point, customers are not crying. Will not need it in the future.

Buffer overflows (memory unsafety) are consistently at the top of the list of bugs leading to vulnerable software.


> - I'll just slap @trusted everywhere and call is a day

Arguably better to slap @system everywhere.


> - I don't think D defaults are wrong, they let you write code that is as-crappy-as-needed and gets better later.

That was indeed the idea behind unsafety as the default. But the programming world has changed. We don't have a choice.


>    There is a performance difference.

Add @system where you must.

On 1/2/2020 5:46 PM, Adam D. Ruppe wrote:
> or just open the debugger and it tells you exactly where it happened.

Oh, if only that were true. (I have decades of experience with this.)

On 1/2/2020 11:40 PM, H. S. Teoh wrote:
> Another issue is that taking the address of locals is verboten in @safe
> code. It's generally found in self-contained code, but becomes a problem
> across 3rd party library API boundaries: if an API requires a pointer
> there's not much you can do about it without waiting for an upstream fix
> (which will break API with older code).

In my experience, the fix for such things is to use `ref T` instead of `T*`. I know you can't change 3rd party code, so simply label those as @system and move on after filing an enhancement request to the 3rd party.

Or you can do this:

    ---- from 3rd Party ----
    module fromThirdParty;
    @system U thirdParty(T* p);

    ---- your code ----
    import fromThirdParty;
    @trusted U thirdParty(ref T t) { return fromThirdParty.thirdParty(&t); }
    ...
    @safe void myParty()
    {
        T local;
        thirdParty(local);
    }

Inlining will remove the wrapper call.

On Friday, 3 January 2020 at 11:29:47 UTC, Walter Bright wrote:
> On 1/2/2020 9:06 AM, Guillaume Piolat wrote:
>> - Never needed memory-safety, don't see the point, customers are not crying. Will not need it in the future.
>
> Buffer overflows (memory unsafety) are consistently at the top of the list of bugs leading to vulnerable software.

I think what will be useful is accepting the change as -preview, let us build with it and then see how many actual bugs it catched.


>> - I'll just slap @trusted everywhere and call is a day
>
> Arguably better to slap @system everywhere.

Absolutely.


> That was indeed the idea behind unsafety as the default. But the programming world has changed. We don't have a choice.

Well yes this sounds like the sort of decision that can avoid loss of millions in the far future. It's just a bit annoying, no biggie.

On Friday, 3 January 2020 at 13:03:52 UTC, Guillaume Piolat wrote:
>
> On Friday, 3 January 2020 at 11:29:47 UTC, Walter Bright wrote:
>> On 1/2/2020 9:06 AM, Guillaume Piolat wrote:
>>> - Never needed memory-safety, don't see the point, customers are not crying. Will not need it in the future.
>>
>> Buffer overflows (memory unsafety) are consistently at the top of the list of bugs leading to vulnerable software.
>
> I think what will be useful is accepting the change as -preview, let us build with it and then see how many actual bugs it catched.

This has been how every other DIP has been introduced, I don't expect this one to be any different.

On Thu, Jan 2, 2020 at 7:50 PM Mike Parker via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> This is the feedback thread for the first round of Community Review for DIP 1028, "Make @safe the Default":
>
> https://github.com/dlang/DIPs/blob/1b705f8d4faa095d6d9e3a1b81d6cfa6d688554b/DIPs/DIP1028.md
>
> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on January 16, or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
>
> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> *Please stay on topic!*
>
> Thanks in advance to all who participate.

FWIW, I'm not emotional about this, but it seems like a really good
opportunity to change @system to @unsafe, since @system appears almost
nowhere in existing code (because is default).
'system' is a weird name for 'unsafe'. I've had lots of colleagues
tell me they think it doesn't make sense... and I agree. It's a silly
name, and defies the industries established terminology for no reason.
We have exactly one opportunity to correct this, and this is it.

On Friday, 3 January 2020 at 11:20:35 UTC, Walter Bright wrote:
On Friday, 3 January 2020 at 11:20:35 UTC, Walter Bright wrote:
> On 1/2/2020 9:20 PM, Arine wrote:
>> On Friday, 3 January 2020 at 01:31:26 UTC, Walter Bright wrote:
>>> This DIP is not about changing how trusted code is inserted. If you'd like to discuss that, please start a separate thread. Please keep this thread on-topic about the DIP.
>> 
>> If issues with @safe aren't going to be considered with this DIP, then I'd say this DIP should be delayed until issues with @safe are resolved before forcing it as the default.
>
> No. We don't have time to do all development serially

Then this would be better served as an opt in feature. This is going to be a big breaking change, and if you are going to do the same thing with `nothrow`, that's way too much breakage for very little benefit just to follow a trend. Especially if steps aren't going to be taken to ensure it is easy to maintain backwards compatibility. As someone else mentions

@system:

does not give the same behavior and will still break code.

> Issues not in bugzilla do not get fixed. Please put all issues with @safe in bugzilla and mark them with the `safe` keyword.
>
> Then, when bringing up a problem or set of problems, link to the corresponding issues.
>
> There's NOTHING AT ALL anyone can do with statements like "needs to use a hack" because nobody has any idea what you're referring to.

There's probably already an issue filed for it. It comes up often. I don't have the time right now to search through tens of thousands of unmanaged issues for you. I already gave an example in my preview post.

On Friday, 3 January 2020 at 11:29:47 UTC, Walter Bright wrote:
> Buffer overflows (memory unsafety) are consistently at the top of the list of bugs leading to vulnerable software.

You should try this new programming language I like a lot. It has built in range checking on this cool feature called slices.

Instead of C style array, you slice the pointer and then the language knows the length and will check it on any access, throwing a range error if you go out of bounds. And with its built in dynamic arrays they are all slices so you don't even need to think about it.

It is an awesome programming language and solves these problems with almost zero programming effort! Check it out some time at https://dlang.org/

On Friday, 3 January 2020 at 11:31:43 UTC, Walter Bright wrote:
> Oh, if only that were true. (I have decades of experience with this.)

I've had a few times when things got outright corrupted in D and those are indeed very difficult to find.

But like my last snarky email said, D is different because we have RangeError. It is very rare that things get out of control here. Even in cases where we want to bypass range error, it can easily be done in isolation meaning the checks still protect you.

This is both good and bad for this dip.

Good: I suspect a majority of D code already qualifies for @safe. The pain impact is likely to be small, and with the default set correctly, more libraries will work and those benefits can bubble up to user code.

Bad: It is a bit of a hassle to deal with breakage when it comes up and the benefit is likely to be small, since most code is already free of the trouble it aims to solve.


I fall a bit on the "yes" side since I do think the good slightly outweighs the bad.

But let's not unfairly trash D as it stands to make this case stronger. We're already streets ahead of C++ even without this dip so talking about bad experiences and overall statistics from C and C++ don't necessarily apply to D.

On 1/3/20 6:43 AM, Manu wrote:
> FWIW, I'm not emotional about this, but it seems like a really good
> opportunity to change @system to @unsafe, since @system appears almost
> nowhere in existing code (because is default).
> 'system' is a weird name for 'unsafe'. I've had lots of colleagues
> tell me they think it doesn't make sense... and I agree. It's a silly
> name, and defies the industries established terminology for no reason.
> We have exactly one opportunity to correct this, and this is it.

+1