Is @safe still a work-in-progress?

[Chris M.]

On Friday, 24 August 2018 at 00:13:48 UTC, Mike Franklin wrote:
> On Thursday, 23 August 2018 at 23:36:07 UTC, Chris M. wrote:
>
>> Heck, now that I'm looking at it, DIP25 seems like a more 
>> restricted form of Rust's lifetimes. Let me know if I'm just 
>> completely wrong about this, but
>
> I think DIP 25 is analogous to Problem #3 for Rust's 
> Non-Lexical Lifetimes:
>
> http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-lexical-lifetimes-introduction/#problem-case-3-conditional-control-flow-across-functions
>
> http://smallcultfollowing.com/babysteps/blog/2016/05/09/non-lexical-lifetimes-adding-the-outlives-relation/#problem-case-3-revisited
>

Seems to be more of a warning of what issues we may face if 
DIP25/DIP1000 are finally implemented. It would be good to 
consider NLLs as well before D is committed. No point in 
repeating issues that have already been studied.

>> would basically be like (pseudosyntax)
>>
>> @safe ref'a int identity(ref'a int x) {
>>     return x; // fine
>> }
>>
>> Maybe the more sane thing would be a syntax that visually ties 
>> them together as above. Obviously we're looking at possibly 
>> breaking changes, but how widespread would they be?
>>
>> void betty(ref'a scope int* r, scope'a int* p); // syntax is 
>> not so nice since I just arbitrarily stuck them on different 
>> keywords, but that's besides the point here
>
> I wish I had been more involved in D when DIP 25 and DIP 1000 
> were being proposed, as I don't think the designs were 
> thoroughly vetted.  It's taken me at least a year to even begin 
> getting a grasp on it.
>
> I think DIP 25 and DIP 1000 should have been combined and 
> thought of holistically as simply "annotated lifetimes in D" 
> rather than separate things.  I think then it becomes easier to 
> visualize what the problem is and see, potentially many, 
> alternatives.
>
> Given the investments that have already been made in DIP 25 and 
> DIP 1000, it's going to take an extremely motivated individual 
> to fight an uphill battle to change direction now, I'm afraid.  
> If working on D was my full-time job, I'd do it, but who in 
> this community has such resources.

I think the main problem is that these were created before the 
DIP process was fully fleshed out, so who knows how much vetting 
they got. At least they are still compiler switches and probably 
not widely used, so it's not like we're already too far gone. I 
do also agree they should be worked on in conjunction, the hard 
part is finding someone to take ownership and put in the extra 
effort.

>
> Mike