[Issue 15932] Get rid of the implicit slicing of static arrays
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Tue Nov 8 12:58:09 UTC 2022
https://issues.dlang.org/show_bug.cgi?id=15932
--- Comment #4 from RazvanN <razvan.nitu1305 at gmail.com> ---
(In reply to hsteoh from comment #3)
> (In reply to RazvanN from comment #2)
> > If you annotate the functions with @safe then you get:
> >
> > test.d(9): Deprecation: reference to local variable `data` assigned to
> > non-scope parameter `_data` calling `this`
>
> That's good to know.
>
>
> > I think that having the compiler automatically slice your static arrays is
> > actually quite nice as you have to type less.
>
> I disagree, the compiler implicitly slicing your static arrays for you has
> the same sort of issues as implicit constructions in C++: they tend to turn
> up where they are unexpected and cause problems.
>
>
> > The fact that you can escape a
> > pointer to an expired stack frame is something that @safe and scope should
> > deal with. Still, in system code this should be perfectly fine.
>
> How can escaping a pointer to an expired stack frame ever be fine?? That is
> never OK and should not be allowed in the language. At least, not
> implicitly. If you want to explicitly escape a reference to a local static
> array, you should be forced to explicitly slice it, not have the compiler
> silently insert it for you.
What I meant was that there are situations where implicit slicing of static
arrays is actually desirable. For example, the standard library can implement
functions that take dynamic arrays and the user can conveniently use static
arrays to call those functions. In most situations that will not lead to
memory corruption and inexperienced users can have a much smoother experience.
Also, the plan is to have DIP1000 and @safe by default, so the situations where
automatically slicing a dynamic array may lead to escaping of pointers to
expired stack frames are going to get caught automatically by default.
If we go down the path to deprecate this behavior we are just going to cause
annoyances for less experienced users for no apparent gain.
--
More information about the Digitalmars-d-bugs
mailing list