On Saturday, 4 January 2020 at 05:43:25 UTC, Jesse Phillips wrote:
> On Friday, 3 January 2020 at 05:57:09 UTC, Jesse Phillips wrote:
>> 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
>>>
>>
>> I think the DIP should specify the depreciation plan. Currently it only mentions it would be available through --preview (is it not expect to go further?
>
> Another thought to depreciation, the compiler could deprecated system functions which aren't marked @system.
>
> This depreciation would ignore all method calls. This basically means functions utilizing unsafe language features must declare that use in the signature.
>
> The next part I'll need to think on is if there is a way to build out the @trusted annotations.

With the above rule in place and taking precedence, the next depreciation would be that unmarked methods could not call into @system methods. This would cause a chain effect until a method was marked trusted or the marking of @system was added to main.

There was an effort to show projects build state if safe was default. These depreciations should have no ill effect on building projects as they will not have unmarked system code.


One of the main benefits here is that it creates a resolution from the bottom up instead of the top down. If @safe were just made default then resolution for what code is trusted would likely favor higher in the call chain will this depreciation approach encourages creation of a trusted interface quickly.

On 08.01.20 08:10, Arine wrote:
> 
> @trusted doesn't really make sense. It is pretty much @system that @safe can call. It's actually kind of bad as how easily it can be misused. @trusted: comes to mind. You can have @trusted destructors. So when you are reading @safe code you can't easily tell where potentially @unsafe code is located. As the @trusted is applied to the function, not at the call site (like Rust/C#).
> ...

This line of reasoning makes no sense.

@trusted void foo(T...)(T args){ ... }

is like

@safe void foo(T...)(T args){ unsafe{ ... } }

It's the same thing. The point is that the interface of foo is assumed to safe by all callers even though the implementation might not be.

> If we are going to make @safe the default we don't really need @safe keyword, or @system or @trusted. It's make sense to get rid of all 3 of them and just add @unsafe. If you are going to do it, might as well do it right the first time.

I don't care all that much either way, but let's not pretend that what you propose is different to what we have in any important way other than how convenient certain things are to express. Adding trusted statement blocks and deprecating `@trusted:` annotations would have essentially the same effect.

On Thu, Jan 9, 2020 at 5:01 AM Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 08.01.20 08:10, Arine wrote:
> >
> > @trusted doesn't really make sense. It is pretty much @system that @safe
> > can call. It's actually kind of bad as how easily it can be misused.
> > @trusted: comes to mind. You can have @trusted destructors. So when you
> > are reading @safe code you can't easily tell where potentially @unsafe
> > code is located. As the @trusted is applied to the function, not at the
> > call site (like Rust/C#).
> > ...
>
> This line of reasoning makes no sense.
>
> @trusted void foo(T...)(T args){ ... }
>
> is like
>
> @safe void foo(T...)(T args){ unsafe{ ... } }
>
> It's the same thing. The point is that the interface of foo is assumed to safe by all callers even though the implementation might not be.
>
> > If we are going to make @safe the default we don't really need @safe keyword, or @system or @trusted. It's make sense to get rid of all 3 of them and just add @unsafe. If you are going to do it, might as well do it right the first time.
>
> I don't care all that much either way, but let's not pretend that what you propose is different to what we have in any important way other than how convenient certain things are to express. Adding trusted statement blocks and deprecating `@trusted:` annotations would have essentially the same effect.

unsafe blocks is distinctly preferable to me. Functions are usually >1 line, and I hate that we can only mark this at the function level. Unsafely statements are never at the function level, it's usually just one line among a larger function. An unsafe scope would be immensely preferable to me, because I can make it as narrow as the code i'm suspicious of, and the surrounding code doesn't lose its safe checking just by being a bystander.

On Thu, Jan 09, 2020 at 10:12:23AM +1000, Manu via Digitalmars-d wrote: [...]
> unsafe blocks is distinctly preferable to me. Functions are usually >1 line, and I hate that we can only mark this at the function level. Unsafely statements are never at the function level, it's usually just one line among a larger function. An unsafe scope would be immensely preferable to me, because I can make it as narrow as the code i'm suspicious of, and the surrounding code doesn't lose its safe checking just by being a bystander.

There is this current idiom that essentially serves as a @trusted block:

	auto myFunc() @safe {
		... // mundane stuff
		() @trusted {
			// dangerous stuff goes here
		}();
		... // more mundane stuff
	}

But it's quite the eyesore, I'll admit.

OTOH, that may be its redeeming quality: it looks so ugly, and is so icky to write, that it discourages people from overusing it. You're inclined to do it only when you absolutely have to.


T

-- 
There's light at the end of the tunnel. It's the oncoming train.

On Thu, Jan 9, 2020 at 10:49 AM H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Thu, Jan 09, 2020 at 10:12:23AM +1000, Manu via Digitalmars-d wrote: [...]
> > unsafe blocks is distinctly preferable to me. Functions are usually >1 line, and I hate that we can only mark this at the function level. Unsafely statements are never at the function level, it's usually just one line among a larger function. An unsafe scope would be immensely preferable to me, because I can make it as narrow as the code i'm suspicious of, and the surrounding code doesn't lose its safe checking just by being a bystander.
>
> There is this current idiom that essentially serves as a @trusted block:
>
>         auto myFunc() @safe {
>                 ... // mundane stuff
>                 () @trusted {
>                         // dangerous stuff goes here
>                 }();
>                 ... // more mundane stuff
>         }
>
> But it's quite the eyesore, I'll admit.
>
> OTOH, that may be its redeeming quality: it looks so ugly, and is so icky to write, that it discourages people from overusing it. You're inclined to do it only when you absolutely have to.

Lambdas are usually suggested, but it's a completely unacceptable hack.
 * additional function call overhead
 * influences the inliner heuristics unfavourably
 * may allocate a closure if you're not careful
 * additional callstack pollutes stack trace with redundant frames
with stupid names, which is particularly annoying while debugging!

This is a tired and unacceptable suggestion.

On 1/2/20 4:47 AM, 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 
> 
> 
> 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.

A consideration I didn't think of before. What happens here?

extern(C) void free(void *ptr);

Is this considered safe now by default? We should not have that be the case.

-Steve

On Thu, Jan 09, 2020 at 12:01:39PM +1000, Manu via Digitalmars-d wrote:
> On Thu, Jan 9, 2020 at 10:49 AM H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
[...]
> >         auto myFunc() @safe {
> >                 ... // mundane stuff
> >                 () @trusted {
> >                         // dangerous stuff goes here
> >                 }();
> >                 ... // more mundane stuff
> >         }
> >
> > But it's quite the eyesore, I'll admit.
[...]
> Lambdas are usually suggested, but it's a completely unacceptable hack.
>  * additional function call overhead
>  * influences the inliner heuristics unfavourably
>  * may allocate a closure if you're not careful
[...]

Oh? Didn't somebody post a PR to inline these lambdas when they appear in such contexts?  Was that never merged, or is it only active with -inline?  Did you check the output asm to see what it actually does?


T

-- 
The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- Anonymous

On Thu, Jan 9, 2020 at 12:34 PM H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Thu, Jan 09, 2020 at 12:01:39PM +1000, Manu via Digitalmars-d wrote:
> > On Thu, Jan 9, 2020 at 10:49 AM H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> [...]
> > >         auto myFunc() @safe {
> > >                 ... // mundane stuff
> > >                 () @trusted {
> > >                         // dangerous stuff goes here
> > >                 }();
> > >                 ... // more mundane stuff
> > >         }
> > >
> > > But it's quite the eyesore, I'll admit.
> [...]
> > Lambdas are usually suggested, but it's a completely unacceptable hack.
> >  * additional function call overhead
> >  * influences the inliner heuristics unfavourably
> >  * may allocate a closure if you're not careful
> [...]
>
> Oh? Didn't somebody post a PR to inline these lambdas when they appear in such contexts?  Was that never merged, or is it only active with -inline?  Did you check the output asm to see what it actually does?

That has never been behaviour I've observed. And GDC/LDC don't have
`-inline`; they defer to their own optimiser. LDC with -O2 doesn't
inline this.
I'm sure you can tickle the things and make this inline, but this will
still affect the compilers heuristics unfavourably leading to poor
optimisation choices regardless.

https://godbolt.org/z/oVdRP9

Abusing a lambda is not a 'feature', it's a terrible hack that
materially changes functionality and has never been a valid
suggestion. I've argued this so many times before.
We should have attributed scopes in the language, this has been a
feature request forever.

On Thursday, 9 January 2020 at 02:34:37 UTC, H. S. Teoh wrote:
> On Thu, Jan 09, 2020 at 12:01:39PM +1000, Manu via Digitalmars-d wrote:
>> On Thu, Jan 9, 2020 at 10:49 AM H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> [...]
>> >         auto myFunc() @safe {
>> >                 ... // mundane stuff
>> >                 () @trusted {
>> >                         // dangerous stuff goes here
>> >                 }();
>> >                 ... // more mundane stuff
>> >         }
>> >
>> > But it's quite the eyesore, I'll admit.
> [...]
>> Lambdas are usually suggested, but it's a completely unacceptable hack.
>>  * additional function call overhead
>>  * influences the inliner heuristics unfavourably
>>  * may allocate a closure if you're not careful
> [...]
>
> Oh? Didn't somebody post a PR to inline these lambdas when they appear in such contexts?  Was that never merged, or is it only active with -inline?  Did you check the output asm to see what it actually does?
>
>
> T

I have a feature branch with a POC [1] of @trusted block statements. I remember that while it worked this was not so nicely done because safety is something that works at the function level so the semantic part consists of a cheat.

[1]: https://c.gmx.com/@558129942915716568/BZ_xc2wjRgWzo3XVZXjVVg

On 1/8/20 9:14 PM, Steven Schveighoffer wrote:
> On 1/2/20 4:47 AM, 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 
>>
>>
>> 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.
> 
> A consideration I didn't think of before. What happens here?
> 
> extern(C) void free(void *ptr);
> 
> Is this considered safe now by default? We should not have that be the case.

extern(C++) prototypes also. Basically, any function where `@safe` does not factor into the function mangled name, and no implementation is present should be assumed to be system.

-Steve