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
