On Thursday, 26 May 2022 at 14:35:57 UTC, deadalnix wrote:
> This is the opposite of progress. Stop it.
I'd be happy to add attributes for something that could actually track ownership/lifetime. DIP1000 is not that. Adding attributes for that is not worth it.
Despite quoting Amaury, my reply is aimed at everyone here.
DIP1000 is sure a difficult concept to learn, and I agree it's onerous to migrate code to use it and it does not discover that much flaws in existing code. But there is one imperative point that I haven't seen mentioned here.
There was a fundamental design flaw in @safe, and DIP1000 is the solution to it. It's not just about enabling new paradigms, it's about plugging a hole in existing one. These compile without the DIP, but are detected by DIP1000:
@safe ref int oops1()
{ int[5] arr;
int[] slice = arr[];
return slice[2];
}
@safe ref int oops2()
{ struct AnInt
{ int here;
int* myAddress()
{ auto result = &here;
return result;
}
}
AnInt myInt;
return *myInt.myAddress;
}
If you're against DIP1000, you have to either:
-
Say that we should resign the purpose of @safe eliminating undefined behaviour from the program. I'd hate that.
-
Say that we should simply disallow slicing static arrays and referencing to address of a struct member from a member function in @safe code. That would break a LOT of code, and would force @safe code to resign quite a deal of performance. I'd hate that.
-
Come up with a better idea for escape checking. For one, I cannot.
One thing I want to mention is that you only need scope if you're going to work with data in the stack. Often it's more pragmatic to just allocate stuff on the heap so you don't have to fight with scope checks.
DIP1000 is currently only scarcely documented. I'm considering doing a series of blog posts to the D blog about DIP1000, that would probably help.
Permalink
Reply
