Is @safe still a work-in-progress?

[rikki cattermole]

On 18/08/2018 1:29 AM, vit wrote:
> 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)

No it shouldn't. You used i there which automatically requires a heap 
allocation for a delegate. Hence it uses GC.