On Tuesday, 15 November 2022 at 14:05:42 UTC, Siarhei Siamashka
wrote:
On Tuesday, 15 November 2022 at 13:16:18 UTC, Paul Backus wrote:
D's safety model is the same. In `@safe` code, D will reject
anything that the compiler cannot say for sure is memory safe.
However, unlike in Rust, `@safe`
On 11/15/22 06:05, Siarhei Siamashka wrote:
> Ali commented that "the
> compiler cannot do anything about it in all cases and we wouldn't want
> it to spend infinite amount of time to try to determine everything".
Yes, that's my understanding.
> This sounds like he justifies the compiler's
On Tuesday, 15 November 2022 at 13:16:18 UTC, Paul Backus wrote:
D's safety model is the same. In `@safe` code, D will reject
anything that the compiler cannot say for sure is memory safe.
However, unlike in Rust, `@safe` is not the default in D, so
you must mark your code as `@safe` manually
On Tuesday, 15 November 2022 at 13:01:39 UTC, Siarhei Siamashka
wrote:
Well, there's another way to look at it:
https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html
('Unsafe Rust exists because, by nature, static analysis is
conservative. When the compiler tries to determine whether or
not
On Tuesday, 15 November 2022 at 06:44:16 UTC, Ali Çehreli wrote:
In summary, you are right but the compiler cannot do anything
about it in all cases and we wouldn't want it to spend infinite
amount of time to try to determine everything.
Well, there's another way to look at it:
On 11/14/22 19:05, Elfstone wrote:
> @safe
> int[] foo()
> {
> int[1024] static_array;
> // return static_array[]; // Error: returning `static_array[]`
> escapes a reference to local variable `static_array`
That is trivial for the compiler to catch.
>
On Tuesday, 15 November 2022 at 04:10:37 UTC, rikki cattermole
wrote:
On 15/11/2022 5:10 PM, Elfstone wrote:
I just checked the DIP list and #1000 is marked superseded.
Any idea what supersedes it?
The implementation.
Cool.
On 15/11/2022 5:10 PM, Elfstone wrote:
I just checked the DIP list and #1000 is marked superseded. Any idea
what supersedes it?
The implementation.
On Tuesday, 15 November 2022 at 03:18:17 UTC, Siarhei Siamashka
wrote:
On Tuesday, 15 November 2022 at 03:05:30 UTC, Elfstone wrote:
So the compiler detects escaping in foo() but not in bar(),
this doesn't look right.
The compiler can detect it with -dip1000 command line option.
Is there a
On Tuesday, 15 November 2022 at 03:05:30 UTC, Elfstone wrote:
So the compiler detects escaping in foo() but not in bar(),
this doesn't look right.
The compiler can detect it with -dip1000 command line option.
Is there a way to tell whether a slice is from a dynamic array
or a static array?
On Tuesday, 15 November 2022 at 02:50:44 UTC, Siarhei Siamashka
wrote:
On Tuesday, 15 November 2022 at 02:26:41 UTC, Elfstone wrote:
By assigning aSlice to arr or a, it seemingly escapes the
scope, I thought there'd be errors, but the code compiles just
fine.
Is it really safe though?
No,
On Tuesday, 15 November 2022 at 02:49:55 UTC, Mike Parker wrote:
It's not the scope that matters here. It's the stack. Memory
allocated in the inner scope uses the function stack, so it's
all valid until the function exits.
And that was just so, so wrong. Of course destructors get called
On Tuesday, 15 November 2022 at 02:26:41 UTC, Elfstone wrote:
By assigning aSlice to arr or a, it seemingly escapes the
scope, I thought there'd be errors, but the code compiles just
fine.
Is it really safe though?
No, it's not safe. You can add `@safe:` line in the beginning of
your
On Tuesday, 15 November 2022 at 02:26:41 UTC, Elfstone wrote:
I failed to find any documentation, except dynamic array slices
will be taken care of by GC, but I assume it's not the case
with static arrays.
A slice is a view on the existing memory owned by the original
array. No allocations
14 matches
Mail list logo
