Re: GCC 10.2.1 Released
On Monday, 24 August 2020 at 23:49:42 UTC, Iain Buclaw wrote: Just out of curiosity, which language version will the next GCC release have? Currently, my version of GDC gives __VERSION__ as 2.076, which is pretty old (whereas LDC gives 2.093, basically on par with DMD). Will the next GDC major release have a significantly-updated language version? Likely the deciding factor will come down to how much free time I will get to do so. There's still a few outstanding issues in dmd-master and gcc middle-end that have hampered progress by a few weeks. Thank you for your work. I cross my fingers for you to have enough free time in the upcoming months!
Re: Blog Post: What Does Memory Safety Really Mean in D?
On Wednesday, 26 August 2020 at 14:29:46 UTC, Dukc wrote:
I think there is a workaround to the variable access being
always safe. Something like this in a dedicated module:
```
struct SystemVar(T, bool safeVal)
{ private T _var;
static if (safeVal) @safe pure nothrow @nogc auto val()
{ return _var;
}
else pure nothrow @nogc auto val(){return _var;}
pure nothrow @nogc ref var(){return _var;}
}
```
This currently does not protect against:
- SystemVar.tupleof[0] (unless you have -preview=dip1000 set)
- __traits(getMember, SystemVar, "_var")
- aliasing (put SystemVar!int in a union with a plain int / cast
SystemVar!int[] from int[])
- void initialization
Re: Blog Post: What Does Memory Safety Really Mean in D?
On 8/26/20 10:29 AM, Dukc wrote:
On Sunday, 23 August 2020 at 19:39:35 UTC, Paul Backus wrote:
https://pbackus.github.io/blog/how-does-memory-safety-work-in-d.html
What exactly do we mean when we talk about "memory safety" in D? Is it
the same thing as "undefined behavior"? Is it ever correct to mark and
`extern(C)` function as `@trusted`? This post is my attempt to
understand, and answer, questions like these.
If you think I've gotten anything wrong, please leave a reply--this is
definitely an area where I'm still learning.
Good post.
I think there is a workaround to the variable access being always safe.
Something like this in a dedicated module:
```
struct SystemVar(T, bool safeVal)
{ private T _var;
static if (safeVal) @safe pure nothrow @nogc auto val()
{ return _var;
}
else pure nothrow @nogc auto val(){return _var;}
pure nothrow @nogc ref var(){return _var;}
}
```
Nice idea. You need to mark everything as @system that should be -- this
is a template, so the compiler is going to happily mark a lot (all?) of
that as @safe.
-Steve
Re: Blog Post: What Does Memory Safety Really Mean in D?
On Sunday, 23 August 2020 at 19:39:35 UTC, Paul Backus wrote:
https://pbackus.github.io/blog/how-does-memory-safety-work-in-d.html
What exactly do we mean when we talk about "memory safety" in
D? Is it the same thing as "undefined behavior"? Is it ever
correct to mark and `extern(C)` function as `@trusted`? This
post is my attempt to understand, and answer, questions like
these.
If you think I've gotten anything wrong, please leave a
reply--this is definitely an area where I'm still learning.
Good post.
I think there is a workaround to the variable access being always
safe. Something like this in a dedicated module:
```
struct SystemVar(T, bool safeVal)
{ private T _var;
static if (safeVal) @safe pure nothrow @nogc auto val()
{ return _var;
}
else pure nothrow @nogc auto val(){return _var;}
pure nothrow @nogc ref var(){return _var;}
}
```
