Is @safe still a work-in-progress?

[vit]

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)