On 1/4/2020 7:59 PM, Jon Degenhardt wrote:
>  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.

DIP1000 and DIP1028 will remain independent effects.

On Saturday, 4 January 2020 at 11:23:24 UTC, rikki cattermole wrote:
>
> There is a solution to all three of the categories that you have described that would be of major benefit to D over all. And it has not been posted on this thread yet.

Actually it has been. But creating a plan to manage these large changes does not appear to be valued and instead everyone is focused on complaining.

This thread is supposed to be direction on improving the DIP not the management of a larger vision. Big

https://forum.dlang.org/post/tlpwfwwakfmowpnwrvcg@forum.dlang.org

On Sunday, 5 January 2020 at 04:07:52 UTC, H. S. Teoh wrote:
> 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

Well you can call @safe code from @system, so you can't really guarantee the value is correct in @safe. Kind of the same situation with an uninitialized bool that evaluates differently because of the code gen. The only way to guarantee it is valid is if you created the variable in @safe and wasn't passed as a parameter.

Anyways, realistically people are just going to use @trusted: more instead of @system: because @trusted: is an actual solution and doesn't require fixing templates and any other anomalies that show up. So yes more code will work with @safe but it won't actually make it safer.

On Sun, Jan 05, 2020 at 04:43:55PM +0000, jxel via Digitalmars-d wrote: [...]
> Well you can call @safe code from @system, so you can't really guarantee the value is correct in @safe.

The guarantees of @safe is conditioned upon being called from other @safe code. As long as somewhere at the top of the call chain there's a @system function, then all bets are off.  This is why this DIP is so important: until main() can become @safe, there's always a possibility that somewhere along the line you screwed up and negated the guarantees of @safe. This is unavoidable; for example a @system main() could have trashed the entire RAM before calling a @safe function, and it's already in UB land when the @safe function runs, so there's no way for the @safe function to guarantee anything.

Our current situation is that we have @system on top of the call chain (because not everything is @safe yet) and maybe some @safe bits lower down or at the bottom.  Where we want to get to is @safe at the top, and small bits of @system at the bottom gated by properly-audited @trusted entry points.  This DIP is an important step in this direction.


> Kind of the same situation with an uninitialized bool that evaluates differently because of the code gen. The only way to guarantee it is valid is if you created the variable in @safe and wasn't passed as a parameter.

D always initializes all locals. Writing `bool b = void;' is @system, so again, once your caller is @system, all bets are off further down the call chain.


> Anyways, realistically people are just going to use @trusted: more instead of @system: because @trusted: is an actual solution and doesn't require fixing templates and any other anomalies that show up. So yes more code will work with @safe but it won't actually make it safer.

If I had my way, I'd outright outlaw "@trusted:" and only allow it on smaller constructs.  If you really wanted to trust an entire module that's essentially @system, just write main() @system and be done with it. Why lie to yourself for no benefit whatsoever?


T

-- 
Life is complex. It consists of real and imaginary parts. -- YHL

On Sunday, 5 January 2020 at 17:57:18 UTC, H. S. Teoh wrote:
> On Sun, Jan 05, 2020 at 04:43:55PM +0000, jxel via Digitalmars-d wrote: [...]
>> Well you can call @safe code from @system, so you can't really guarantee the value is correct in @safe.
>
> The guarantees of @safe is conditioned upon being called from other @safe code. As long as somewhere at the top of the call chain there's a @system function, then all bets are off.  This is why this DIP is so important: until main() can become @safe, there's always a possibility that somewhere along the line you screwed up and negated the guarantees of @safe. This is unavoidable; for example a @system main() could have trashed the entire RAM before calling a @safe function, and it's already in UB land when the @safe function runs, so there's no way for the @safe function to guarantee anything.
>
> Our current situation is that we have @system on top of the call chain (because not everything is @safe yet) and maybe some @safe bits lower down or at the bottom.  Where we want to get to is @safe at the top, and small bits of @system at the bottom gated by properly-audited @trusted entry points.  This DIP is an important step in this direction.

What if you have a @safe library that gets called from another program that is @system. You can't guarantee anything. If safety matters to you then use it. Its not going to stop bad code. If someone gets an error and inserting @trusted gets it to compile, or they can spend 2-4 hours restructuring code, they are going to use the option that doesn't waste their time.

>> Kind of the same situation with an uninitialized bool that evaluates differently because of the code gen. The only way to guarantee it is valid is if you created the variable in @safe and wasn't passed as a parameter.
>
> D always initializes all locals. Writing `bool b = void;' is @system, so again, once your caller is @system, all bets are off further down the call chain.


Bzz, wrong. You can void initialize in @safe.


>> Anyways, realistically people are just going to use @trusted: more instead of @system: because @trusted: is an actual solution and doesn't require fixing templates and any other anomalies that show up. So yes more code will work with @safe but it won't actually make it safer.
>
> If I had my way, I'd outright outlaw "@trusted:" and only allow it on smaller constructs.  If you really wanted to trust an entire module that's essentially @system, just write main() @system and be done with it. Why lie to yourself for no benefit whatsoever?
>
>
> T

If its safe by default, throwing @system: at the top won't work for everything. It'll stop template auto inferring, so @trusted is the only real simple solution. If you are using @system, it doesn't matter to you cause you don't get that safety anyways. Its a matter of getting your code to compile again, @trusted is going to be the quickest easiest solution.

On 05.01.20 18:57, H. S. Teoh wrote:
> Writing `bool b = void;' is @system

I wish.

https://issues.dlang.org/show_bug.cgi?id=19968
https://github.com/dlang/dlang.org/pull/2260
https://issues.dlang.org/show_bug.cgi?id=20148

On 1/5/2020 12:13 PM, jxel wrote:
> inserting @trusted gets it to compile, or they can spend 2-4 hours restructuring code, they are going to use the option that doesn't waste their time.

This misses the point. D provides plenty of escapes from writing safe code. The point is not to stop all those escapes, but to:

1. make it clear where those escapes are

2. make it auditable, i.e. the QA dept can grep for `@trusted` and then decide whether to have a company standard about that or not. In the absence of such, the code is not auditable.

For example, in C:

    void foo() { int* p; } // initialized to garbage

This is not auditable. Whereas in D:

    @system void foo() { int* p = void; } // initialized to garbage

*is* auditable and is intentional and requires extra effort, it is not the default.

On Monday, 6 January 2020 at 02:17:42 UTC, Walter Bright wrote:
> On 1/5/2020 12:13 PM, jxel wrote:
>> inserting @trusted gets it to compile, or they can spend 2-4 hours restructuring code, they are going to use the option that doesn't waste their time.
>
> This misses the point. D provides plenty of escapes from writing safe code. The point is not to stop all those escapes, but to:
>
> 1. make it clear where those escapes are
>
> 2. make it auditable, i.e. the QA dept can grep for `@trusted` and then decide whether to have a company standard about that or not. In the absence of such, the code is not auditable.
>
> For example, in C:
>
>     void foo() { int* p; } // initialized to garbage
>
> This is not auditable. Whereas in D:
>
>     @system void foo() { int* p = void; } // initialized to garbage
>
> *is* auditable and is intentional and requires extra effort, it is not the default.

There seems to be a disconnect of Practicality Vs. Ideology here. I had a similar argument with someone who was distained with std::map<> for being implemented as an ordered map instead of as a hash map. That the basic map should be a hash map as in the general case you don't need it to be sorted and you pay for the performance impact. That its intuitive and what people expect of the basic map type to be implemented as a hash map. This isn't practical to do.

I agree with your ideology, it is sound. The price you have to pay for it though, is too high. In my opinion. If you don't think it is, no one can stop you.

On 1/4/2020 2:45 AM, matheus wrote:
> So isn't this will create a trend where when developer is bothered by the compiler then they will just do this and in the end "safety" will never be achieve?

D has lots of ways to avoid compiler checks. It's up to you to use them or not.

On 1/5/2020 3:48 PM, Timon Gehr wrote:
> On 05.01.20 18:57, H. S. Teoh wrote:
>> Writing `bool b = void;' is @system
> 
> I wish.
> 
> https://issues.dlang.org/show_bug.cgi?id=19968
> https://github.com/dlang/dlang.org/pull/2260
> https://issues.dlang.org/show_bug.cgi?id=20148

I'm glad there's a bugzilla for it marked with the `safe` keyword so I don't have to harangue anyone :-)