--------
import std.algorithm, std.stdio;

@safe:

auto foo() {
  int[6] xs = [0, 1, 2, 3, 4, 5];
  return xs[].map!(x => x);
}

void main() {
  writeln(foo());
}
--------

https://run.dlang.io/is/qC7HUR

For me this gives:

--------
[0, 0, -2132056872, 22008, 0, 0]
--------

Which looks like its just reading arbitrary memory.

I've filed https://issues.dlang.org/show_bug.cgi?id=19175

My question is: what is the status of @safe? I am quite surprised to see such a simple case fail. Is @safe believed to be fully implemented (modulo bugs) and this is just an unfortunate corner case, or is it known work-in-progress?

On Friday, August 17, 2018 1:19:25 AM MDT Peter Alexander via Digitalmars-d wrote:
> --------
> import std.algorithm, std.stdio;
>
> @safe:
>
> auto foo() {
>    int[6] xs = [0, 1, 2, 3, 4, 5];
>    return xs[].map!(x => x);
> }
>
> void main() {
>    writeln(foo());
> }
> --------
>
> https://run.dlang.io/is/qC7HUR
>
> For me this gives:
>
> --------
> [0, 0, -2132056872, 22008, 0, 0]
> --------
>
> Which looks like its just reading arbitrary memory.
>
> I've filed https://issues.dlang.org/show_bug.cgi?id=19175
>
> My question is: what is the status of @safe? I am quite surprised to see such a simple case fail. Is @safe believed to be fully implemented (modulo bugs) and this is just an unfortunate corner case, or is it known work-in-progress?

That particular bug is a duplicate of https://issues.dlang.org/show_bug.cgi?id=8838, which was closed as fixed based on the fact that -dip1000 fixes the problem by treating marking the slice of a static array with scope. It's still quite broken without -dip1000 though.

Honestly, the reality of the matter is that @safe is probably always going to be somewhat broken, because it's implemented via blacklisting rather than whitelisting. Instead of @safe only allowing stuff that's been proven to be @safe, it disallows stuff that a programmer decided was @system. The bug you ran into is a pretty glaring one that arguably should have been fixed ages ago, but given how hard it is to prove what is and isn't @safe, there are bound to be corner cases which have been missed. As we find them, they'll be fixed, but who knows how many are left or whether we'll ever actually get them all.

- Jonathan M Davis

On Friday, 17 August 2018 at 07:50:32 UTC, Jonathan M Davis wrote:

> That particular bug is a duplicate of https://issues.dlang.org/show_bug.cgi?id=8838, which was closed as fixed based on the fact that -dip1000 fixes the problem by treating marking the slice of a static array with scope. It's still quite broken without -dip1000 though.

It still appears to be broke even with -dip1000:  https://run.dlang.io/is/gJi2Fa

On Friday, 17 August 2018 at 07:50:32 UTC, Jonathan M Davis wrote:
> On Friday, August 17, 2018 1:19:25 AM MDT Peter Alexander via Digitalmars-d wrote:
>> [...]
>
> That particular bug is a duplicate of https://issues.dlang.org/show_bug.cgi?id=8838, which was closed as fixed based on the fact that -dip1000 fixes the problem by treating marking the slice of a static array with scope. It's still quite broken without -dip1000 though.
>
> [...]

What's the state of -dip1000?

On Friday, August 17, 2018 2:23:20 AM MDT vit via Digitalmars-d wrote:
> On Friday, 17 August 2018 at 07:50:32 UTC, Jonathan M Davis wrote:
> > On Friday, August 17, 2018 1:19:25 AM MDT Peter Alexander via
> >
> > Digitalmars-d wrote:
> >> [...]
> >
> > That particular bug is a duplicate of https://issues.dlang.org/show_bug.cgi?id=8838, which was closed as fixed based on the fact that -dip1000 fixes the problem by treating marking the slice of a static array with scope. It's still quite broken without -dip1000 though.
> >
> > [...]
>
> What's the state of -dip1000?

Well, I _think_ that aside from bugs (which may or may not be a small number), the compiler implementation is complete. However, there's still a fair bit of work to do in Phobos to make it fully work with -dip1000. And AFAIK, we still don't have a real plan as to how we're going to make -dip1000 the default. But given how much -dip1000 seems to break, I don't know how we're going to switch to it being the default without being highly disruptive in the process.

- Jonathan M Davis

On Friday, 17 August 2018 at 08:23:20 UTC, vit wrote:
> On Friday, 17 August 2018 at 07:50:32 UTC, Jonathan M Davis wrote:
>> On Friday, August 17, 2018 1:19:25 AM MDT Peter Alexander via Digitalmars-d wrote:
>>> [...]
>>
>> That particular bug is a duplicate of https://issues.dlang.org/show_bug.cgi?id=8838, which was closed as fixed based on the fact that -dip1000 fixes the problem by treating marking the slice of a static array with scope. It's still quite broken without -dip1000 though.
>>
>> [...]
>
> What's the state of -dip1000?

I've been using -dip1000 a lot lately. I hit two bugs yesterday. When it works, it's great, _except_:

. @safe isn't default
. -dip1000 isn't default
. Good luck figuring out why your template functions aren't @safe and coaxing the compiler to tell you why it's inferring the attributes it is. Bonus points if it's a Phobos function so you can't slap `@safe` on its definition.

Take excel-d for instance. The other day somebody filed a bug because Excel was crashing when they wrapped some D code that uses std.regex. After investigating I found out that regex memoizes the string with the regular expression in it, effectively escaping the string passed from Excel to the D function. Unfortunately for everyone involved, that string came from a region allocator, and after bumping the pointer back, boom.

Telling people to not escape reference parameters doesn't really work, because nobody will read that part of the README, and, as in the example above, the user didn't even know they were doing it!

Ok, so as a good library author, I tried to make it a compile-time error to shoot yourself in the foot that way, and I did. Great, right? Well, no. I can't force the user to write @safe functions, much less to compile with -dip1000. I changed the example XLL to use -dip1000 because more likely than not users will copy the example and edit it. But I can't force them to write @safe functions, and if they don't (the likeliest scenario given it's not the default), they'll be able to escape whatever it is they want, Excel will crash, and the compiler will be ok with it.

And if they _do_ write @safe functions and compile with -dip1000, chances are at some point they won't understand the compiler error message, make their function @trusted and... crash.
I don't know that because I have a crystal ball, I know that because I did it myself this week. Twice.

Did I mention the bugs? I wrote about my interesting experiences from this week with -dip1000 here:

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

On 17/08/2018 11:33 PM, Atila Neves wrote:
> . Good luck figuring out why your template functions aren't @safe and coaxing the compiler to tell you why it's inferring the attributes it is. Bonus points if it's a Phobos function so you can't slap `@safe` on its definition.

Sure you can. It's a template so it'll be initialized as its required.

I've done that to fix a bug in druntime before and in my own libraries.

On Friday, 17 August 2018 at 11:37:54 UTC, rikki cattermole wrote:
> On 17/08/2018 11:33 PM, Atila Neves wrote:
>> . Good luck figuring out why your template functions aren't @safe and coaxing the compiler to tell you why it's inferring the attributes it is. Bonus points if it's a Phobos function so you can't slap `@safe` on its definition.
>
> Sure you can. It's a template so it'll be initialized as its required.
>
> I've done that to fix a bug in druntime before and in my own libraries.

It's not easy though. You have to either be building your own phobos or sudo editing files in /usr/include. You can, but it's a pain. Then there's finding out exactly where in a chain of 10 template functions that it became @system...

On Friday, August 17, 2018 6:30:26 AM MDT Atila Neves via Digitalmars-d wrote:
> On Friday, 17 August 2018 at 11:37:54 UTC, rikki cattermole wrote:
> > On 17/08/2018 11:33 PM, Atila Neves wrote:
> >> . Good luck figuring out why your template functions aren't @safe and coaxing the compiler to tell you why it's inferring the attributes it is. Bonus points if it's a Phobos function so you can't slap `@safe` on its definition.
> >
> > Sure you can. It's a template so it'll be initialized as its required.
> >
> > I've done that to fix a bug in druntime before and in my own libraries.
>
> It's not easy though. You have to either be building your own phobos or sudo editing files in /usr/include. You can, but it's a pain. Then there's finding out exactly where in a chain of 10 template functions that it became @system...

The reality of the matter is that you tend to have to be very motivated to make your code @safe if you're doing much with templates (the same with other attributes such as pure). And sadly, it can quickly get to the point that it just feels like it's not worth it in spite of the fact that there is definitely value to be had in using them.

I wonder what it would take to make it so that the compiler could actually tell you where in the function call chain it first becomes @system.

- Jonathan M Davis

On Friday, 17 August 2018 at 13:02:20 UTC, Jonathan M Davis wrote:
> On Friday, August 17, 2018 6:30:26 AM MDT Atila Neves via Digitalmars-d wrote:
>> On Friday, 17 August 2018 at 11:37:54 UTC, rikki cattermole wrote:
>> > On 17/08/2018 11:33 PM, Atila Neves wrote:
>> >> . Good luck figuring out why your template functions aren't @safe and coaxing the compiler to tell you why it's inferring the attributes it is. Bonus points if it's a Phobos function so you can't slap `@safe` on its definition.
>> >
>> > Sure you can. It's a template so it'll be initialized as its required.
>> >
>> > I've done that to fix a bug in druntime before and in my own libraries.
>>
>> It's not easy though. You have to either be building your own phobos or sudo editing files in /usr/include. You can, but it's a pain. Then there's finding out exactly where in a chain of 10 template functions that it became @system...
>
> The reality of the matter is that you tend to have to be very motivated to make your code @safe if you're doing much with templates (the same with other attributes such as pure). And sadly, it can quickly get to the point that it just feels like it's not worth it in spite of the fact that there is definitely value to be had in using them.
>
> I wonder what it would take to make it so that the compiler could actually tell you where in the function call chain it first becomes @system.
>
> - Jonathan M Davis

Does -dip1000 affect alias template parameters and closures?
example:

import std.experimental.all;


void main()@safe @nogc{
    int i = 2;

    const x = iota(0, 10)
        .filter!((x)scope => x == i)
        .map!((x)scope => x * x)
        .front;	

    assert(x == 4);
}

onlineapp.d(4): Error: function `D main` is @nogc yet allocates closures with the GC
onlineapp.d(8):        onlineapp.main.__lambda1 closes over variable i at onlineapp.d(5)