On 1/4/2020 3:23 AM, rikki cattermole wrote:
> We defer this going live till D3.

D's future will be in incremental improvements, not creating a new language.

On 1/4/2020 10:51 AM, Gregor Mückl wrote:
> [...]
The transition plan of starting with -preview=feature and eventually changing it to -revert=feature has so far been satisfactory. It gives people plenty of warning and an ability to transition at their own pace.

On 1/4/2020 12:19 PM, Sebastiaan Koppe wrote:
> That makes no sense to me. Instead of sane defaults I am expected to prepend every file with some customary intro? And even if I do that, probably no dependency I use does. Just like hardly any dub package is bothered to do @safe right now.

With D, I have repeatedly learned the lesson of the value of having the right thing by default, so no action is required by the user. It's surprisingly enormous.

Regrettably I did not push for @safe by default many years ago.

On Saturday, 4 January 2020 at 20:19:09 UTC, Sebastiaan Koppe wrote:
> On Saturday, 4 January 2020 at 19:37:43 UTC, jxel wrote:
>> To use an argument that is being used against why this shouldn't happen. You can just do:
>>
>> @safe:
>>
>> Its nice and easy and does what you want, then you can annotate everything else that needs to with @system.
>
> That makes no sense to me. Instead of sane defaults I am expected to prepend every file with some customary intro? And even if I do that, probably no dependency I use does. Just like hardly any dub package is bothered to do @safe right now.

I looked at a few of the dub packages that work with the safe transition, some of them just had @trusted: at the top. A lot of thr ones that did work were small or entirely templated. Dub honestly isnt the best place to look at good code anyways.

Is that your goal, you want to force @safe on people so that their code works with your code?

You want sane defaults at the cost of breaking almost every piece of code out there. As well as any tutorials, examples, and documentation. That's the definition of insanity.

What is a good default depends on what the person uses for D. Anyone that uses @system will make the same argument as you, why should they preface every file with @system:. Such anecdotal rationale isnt good enough.


> Besides, it doesn't work for everything, I have tried.

Exactly the point, people are trying to push @system: as some easy alternative solution. Its not.

On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:
>
> 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.

Has anybody looked at performance considerations since @safe mandates bounds checking is left on in release mode?

On 1/4/20 4:17 PM, Walter Bright wrote:
> On 1/4/2020 2:22 AM, WebFreak001 wrote:
>> Currently a lot of issues are caused by phobos' std.bitmanip.bitfields.
> 
> Please add all issues to Bugzilla.

This isn't an issue, because the DIP is not part of the language yet.

The problem is that a function used by CTFE in there is not marked, and does an array cast (so safe by default rejects it). I've already submitted a change, and it's already helped with WebFreak's tests: https://github.com/dlang/phobos/pull/7343.

Should be merged shortly.

-Steve

On 05/01/2020 10:25 AM, Walter Bright wrote:
> On 1/4/2020 3:23 AM, rikki cattermole wrote:
>> We defer this going live till D3.
> 
> D's future will be in incremental improvements, not creating a new language.

I did not suggest a new language.

I have said this for many years, D3 will be from philosophical changes, not technical and @safe by default is a perfect candidate for that.

On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker 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

From the discussions it appears the amount and nature of breakage will depend on whether DIP1000 is enabled. Assuming this is true, it make sense to discuss DIP1000 in DIP1028. For example:
* Is implementation of DIP1028 dependent on making DIP1000 or something similar the default?
* If DIP1000 is not the default when '-preview=safedefault' becomes available, will '-preview=safedefault' have the effect of turning on the '-preview=dip1000'?
* Discussion of the types of breakage that will be avoided by having DIP1000 enabled.

--Jon

On Sat, Jan 04, 2020 at 10:35:19PM +0000, jxel via Digitalmars-d wrote: [...]
> I looked at a few of the dub packages that work with the safe transition, some of them just had @trusted: at the top.
[...]

Yikes. Which packages are those?  Blanket @trusted at the top of a file is a huge anti-pattern, and a big red flag that the code is *not* to be trusted.

Proper use of @trusted dictates that it should be as small and as contained as possible, and that it should only be applied to functions that export a safe API. I.e., this:

	void trustedMemset(void* buf, size_t sz, ubyte data) @trusted

is flat-out wrong code, because there is no way to ensure that the parameters received by the function are actually safe. The correct signature is:

	void trustedMemset(void[] buf, ubyte data) @trusted

because the slice ensures that the length will always be consistent with the actual buffer size when passed from @safe code. (Of course, all bets are off if the caller is @system.)

There is no way you can check an entire module this way *and* ensure it continues to obey this rule over time in the face of ongoing code changes. (And that's not to mention the respective function bodies, all of which must be vetted before it can be trusted.) I absolutely do not trust any module that has @trusted: at the top.


T

-- 
Spaghetti code may be tangly, but lasagna code is just cheesy.

On 1/4/2020 6:44 PM, Steven Schveighoffer wrote:
> The problem is that a function used by CTFE in there is not marked, and does an array cast (so safe by default rejects it). I've already submitted a change, and it's already helped with WebFreak's tests: https://github.com/dlang/phobos/pull/7343.
> 
> Should be merged shortly.

Good!