DIP 1025--Dynamic Arrays Only Shrink, Never Grow--Community Review Round 1
sireeshkodali1 at gmail.com
Mon Nov 11 16:35:37 UTC 2019
On Monday, 11 November 2019 at 10:27:26 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community
> Review for DIP 1025, "Dynamic Arrays Only Shrink, Never Grow":
> All review-related feedback on and discussion of the DIP should
> occur in this thread. The review period will end at 11:59 PM ET
> on November 25, or when I make a post declaring it complete.
> At the end of Round 1, if further review is deemed necessary,
> the DIP will be scheduled for another round of Community
> Review. Otherwise, it will be queued for the Final Review and
> Formal Assessment.
> Anyone intending to post feedback in this thread is expected to
> be familiar with the reviewer guidelines:
> *Please stay on topic!*
> Thanks in advance to all who participate.
I get what the DIP is trying to do, but like Jonathon said, this
solution is simply not worth the cost *at all*. Such a change
would alienate the existing users, make a lot of good, working
code break for no real reason, and cause a lot of other issues.
The better solution IMO is to instead set an allocator, either
per thread or global, like std.experimental.allocator does. Then,
change the runtime to allocate and expand slices by using that
allocator, instead of the GC. The allocator could be GC by
default. Maybe once that is done, slicing arbitrary pointers
could be depreciated. Then the `@safe` aspect would be solved,
and there would be practically 0 code breakage.
Something like this:
import core.allocator; //hypothetical
void f(int x) @safe
x ~= 0;
void main() @system
int slice = (cast(int*)(malloc(10 * int.sizeof)))[0 .. 10];
this_thread.allocator = Mallocator;
int slice = new int;
f(slice); //now safe, since mallocator is used instead of GC
More information about the Digitalmars-d