Re: Beerconf June 2022
On 6/12/22 2:06 PM, Steven Schveighoffer wrote: # BEERCONF! This month we are celebrating 2 years of monthly online beerconf. That's right, 2 years ago in June 2020 was the first time we started this, when live dconf was supposed to happen, but was canceled. We've had one every month since! A reminder, this is happening in 2 days (for me), and 1 day (for some). Will post a link when it starts, see you then! -Steve
Re: DIP1000: Memory Safety in a Modern System Programming Language Pt.1
On Thursday, 23 June 2022 at 14:08:15 UTC, Steven Schveighoffer
wrote:
On 6/23/22 8:01 AM, Dukc wrote:
On Thursday, 23 June 2022 at 00:37:24 UTC, Steven
Schveighoffer wrote:
You mean like a system function which removes the scope-ness
of an array? Let me introduce you to my other thread:
https://forum.dlang.org/thread/t7qd45$1lrb$1...@digitalmars.com
You are allowed to remove `scope` from an argument in unsafe
code. It's only if you escape that argument when you trigger
undefined behaviour. Just like you can cast away `const`, if
you don't actually mutate the cast variable.
And what do you think a custom struct that circumvents the
scopeness is going to do with that parameter?
To be clear, I think we're talking about something like:
```d
struct ScopeArray(T)
{
T[] arr;
@system void opAssign(scope T[] param)
{
arr = param; // escaping scope
}
}
```
-Steve
By `return scope`. I'm not sure if it'd work with that `opAssign`
example since we don't actually return the `this` pointer. I need
to recheck what `return scope` means with `void` return type,
before I write the next article - There is or at least was some
rule regarding that situation.
But in any case you could accomplish the same with
```D
@safe ScopeArray!T(T)(return scope T[] param)
{ return ScopeArray!T(param);
}
```
. Note that in this case you are not even trying to store `scope`
variables as elements to an array, so we don't need `@trusted`.
Re: DIP1000: Memory Safety in a Modern System Programming Language Pt.1
On 6/23/22 8:14 AM, Kagamin wrote:
On Wednesday, 22 June 2022 at 20:48:13 UTC, Steven Schveighoffer wrote:
Sometimes algorithms require manipulation of structure, such as
sorting arrays, or using linked lists, and sometimes it's nice to be
able to point at things on the stack, temporarily. This is one of the
things I was looking forward to with dip1000, since it does allow
pointing at the stack when it can work out the details.
This works:
```
struct S
{
int[] a;
int[] get() return scope @safe { return a; }
void set(return int[] b) return scope @safe
{ a=b; }
}
int[] f() @safe
{
int[2] a;
scope S t;
int[] b=t.get;
t.set=a;
return b; //no
}
```
This is just saying the same thing -- you must allocate your data on the
stack in order to have scope elements assignable. This isn't always
feasible.
```d
scope a = "first";
scope b = "second";
string[2] x = [a, b];
auto arr = x[]; // ok
arr = ["first", "second"]; // ok
arr = [a, b]; // not ok
```
It's established that arr is attributed such that it's able to point at
stack data. Fine.
It can also point at allocated data. Fine.
But the *allocated data itself* cannot point at scope data. This
"somewhat" makes sense, because by the time the GC cleans up this array,
the data is likely invalid (not in this case, but that's because we
deliberately labeled non-scope data as scope).
However, you may need to mix both non-scope and scope data, which means
you can't allocate on the stack. But there can be ways to mitigate this:
1. For this simple case, just allocate [a, b] on the stack. It's
happening in other places (see my other thread), why not here?
2. The compiler could insert a call at the end of the scope to free the
allocated data. It can't escape anyway, and freeing it early is part of
the benefit of having scope. Or if it's determined that no destructors
are involved, just let the GC clean it up.
The more cases where we make this painless for the user, the better.
-Steve
Re: DIP1000: Memory Safety in a Modern System Programming Language Pt.1
On 6/23/22 8:01 AM, Dukc wrote:
On Thursday, 23 June 2022 at 00:37:24 UTC, Steven Schveighoffer wrote:
You mean like a system function which removes the scope-ness of an
array? Let me introduce you to my other thread:
https://forum.dlang.org/thread/t7qd45$1lrb$1...@digitalmars.com
You are allowed to remove `scope` from an argument in unsafe code. It's
only if you escape that argument when you trigger undefined behaviour.
Just like you can cast away `const`, if you don't actually mutate the
cast variable.
And what do you think a custom struct that circumvents the scopeness is
going to do with that parameter?
To be clear, I think we're talking about something like:
```d
struct ScopeArray(T)
{
T[] arr;
@system void opAssign(scope T[] param)
{
arr = param; // escaping scope
}
}
```
-Steve
Re: DIP1000: Memory Safety in a Modern System Programming Language Pt.1
On Wednesday, 22 June 2022 at 20:48:13 UTC, Steven Schveighoffer
wrote:
Sometimes algorithms require manipulation of structure, such as
sorting arrays, or using linked lists, and sometimes it's nice
to be able to point at things on the stack, temporarily. This
is one of the things I was looking forward to with dip1000,
since it does allow pointing at the stack when it can work out
the details.
This works:
```
struct S
{
int[] a;
int[] get() return scope @safe { return a; }
void set(return int[] b) return scope @safe
{ a=b; }
}
int[] f() @safe
{
int[2] a;
scope S t;
int[] b=t.get;
t.set=a;
return b; //no
}
```
Re: DIP1000: Memory Safety in a Modern System Programming Language Pt.1
On Thursday, 23 June 2022 at 00:37:24 UTC, Steven Schveighoffer wrote: You mean like a system function which removes the scope-ness of an array? Let me introduce you to my other thread: https://forum.dlang.org/thread/t7qd45$1lrb$1...@digitalmars.com -Steve You are allowed to remove `scope` from an argument in unsafe code. It's only if you escape that argument when you trigger undefined behaviour. Just like you can cast away `const`, if you don't actually mutate the cast variable.
Re: DIP1000: Memory Safety in a Modern System Programming Language Pt.1
On Wednesday, 22 June 2022 at 21:58:07 UTC, Ola Fosheim Grøstad wrote: Some C programmers reuse variables extensively, those programmers will be confused or annoyed. And rightly so. Misra says since 30 years or longer: don't reuse variables if possible (and it should almost always be possible). If there exists now another way to shoot in your foot with this bad habit, so what?
Re: DIP1000: Memory Safety in a Modern System Programming Language Pt.1
On Thursday, 23 June 2022 at 06:52:48 UTC, Ola Fosheim Grøstad wrote: On Thursday, 23 June 2022 at 06:36:23 UTC, Ola Fosheim Grøstad wrote: Track the object instead and don’t change the type of the pointer to scope. I guess this is flow typing too, but it is less intrusive to say that the object is either of type «scope» or type «heap» and that regular pointers can hold both than to change the concrete pointer type. Specified concrete types should not change. For people interested in getting more intuition for flow typing: https://www.typescriptlang.org/docs/handbook/2/narrowing.html or chapter 3: https://whiley.org/pdfs/GettingStartedWithWhiley.pdf
