Re: DLF September 2023 Monthly Meeting Summary
On Monday, 13 November 2023 at 16:09:51 UTC, Guillaume Piolat wrote: On Sunday, 12 November 2023 at 19:50:02 UTC, Mike Parker wrote: https://gist.github.com/mdparker/f28c9ae64f096cd06db6b987318cc581 Thanks for the detailed summary, I'm reading them all! Seconded, though I didn't follow all of it...
Re: DLF September 2023 Monthly Meeting Summary
On Monday, 13 November 2023 at 16:23:05 UTC, Tim wrote: The visitor can already be `extern(D)`. Only member functions overriding those in the base class need to be `extern(C++)`. Other member functions can then use paratemers, which would be incompatible with `extern(C++)`. Wow, it really was that simple all along. Thanks for the tip!
Re: DLF September 2023 Monthly Meeting Summary
On Sunday, 12 November 2023 at 21:55:31 UTC, Paul Backus wrote: Personally, my number-one complaint with dmd-as-a-library is that I am forced to use `extern(C++)` when creating my own `Visitor` classes. In [`dmdtags`][1], this requirement has made it necessary for me to implement my own C++-compatible [`Span`][2] and [`Appender`][3] types, just to avoid the C++ mangling errors caused by D's built-in `T[]` slices. I have no use for overriding AST nodes, but the ability to use `extern(D)` visitors with dmd-as-a-library would be a welcome improvement. The visitor can already be `extern(D)`. Only member functions overriding those in the base class need to be `extern(C++)`. Other member functions can then use paratemers, which would be incompatible with `extern(C++)`.
Re: DLF September 2023 Monthly Meeting Summary
On Sunday, 12 November 2023 at 19:50:02 UTC, Mike Parker wrote: https://gist.github.com/mdparker/f28c9ae64f096cd06db6b987318cc581 Thanks for the detailed summary, I'm reading them all!
Re: DLF September 2023 Monthly Meeting Summary
On Monday, 13 November 2023 at 10:01:23 UTC, RazvanN wrote: On Sunday, 12 November 2023 at 21:55:31 UTC, Paul Backus wrote: I have no use for overriding AST nodes, but the ability to use `extern(D)` visitors with dmd-as-a-library would be a welcome improvement. I have already brought that up to one of our work group meetings regarding dmd as a library as I have stumbled upon this also. We have a solution for this, I'm going to try to implement it this week. That's great to hear! Thanks for letting me know.
Re: DLF September 2023 Monthly Meeting Summary
Agreed, getting good locking support is critical for safe memory handling at the process level. Shared as we know it today, is just a distraction from this goal.
Re: DLF September 2023 Monthly Meeting Summary
On Monday, 13 November 2023 at 00:18:35 UTC, Richard (Rikki)
Andrew Cattermole wrote:
Part of the problem with shared is that it is completely
inverse of what it should be.
It fundamentally does not annotate memory with anything extra
that is useful.
At the CPU level there are no guarantees that memory is mapped
only to one thread, nor at the language level.
Therefore all memory is shared between threads.
As long as people have this inverted mindset in place and
instead of wanting to prove its thread owned shared is going to
be a problem for us.
Remove shared, add atomic storage class. Figure out thread
owned/shared memory some other day.
Just to once again add my own view, since I don't see it
represented a lot:
Remove shared or don't, at least *stop making `synchronized`
imply `shared`.* I don't care about shared, I don't care about
atomics, I want to use the mutex style of protecting access,
where I manually think about who exclusively owns what memory.
But I can't use `synchronized`, because then I have to cast
*every access to `this`,* which is clearly insane, and as a
result invariant-using class code is *straight up incorrect,*
because I have literally no choice but to do this:
```
class Foo
{
private int[] array;
invariant { synchronized (this) { assert(this.array.all!(i => i
> 0)); } }
void foo(int i)
in (i > 0)
{
synchronized (this)
{
// Note that the invariant on `array` is not actually
guaranteed here!
// Some other method in another thread might currently have
set up a violation
// for it, but switched out before its out invariant could
be locked and tested.
// So we can have a *wrong invariant in this method,* which
has done absolutely
// nothing wrong. Very fun!!
array ~= i;
}
}
}
```
The only way to prevent this is `synchronized class`, but even if
all missing features are implemented, `array` would be `shared`.
Which is just wrong, as `array` is *privately owned storage of
the class,* a fact I cannot prove to the compiler but is
nonetheless true. `synchronized class` brings in the one feature
I don't want to use and makes it an unavoidable condition of
*literally writing correct code at all*. So yeah `shared`, I
didn't *want* to be your enemy but apparently you wanted to be
mine. `shared` delenda est.
Re: DLF September 2023 Monthly Meeting Summary
On Sunday, 12 November 2023 at 21:55:31 UTC, Paul Backus wrote: On Sunday, 12 November 2023 at 19:50:02 UTC, Mike Parker wrote: https://gist.github.com/mdparker/f28c9ae64f096cd06db6b987318cc581 There was a side discussion about how the `extern(C++)` interface affects dmd-as-a-library. Personally, my number-one complaint with dmd-as-a-library is that I am forced to use `extern(C++)` when creating my own `Visitor` classes. In [`dmdtags`][1], this requirement has made it necessary for me to implement my own C++-compatible [`Span`][2] and [`Appender`][3] types, just to avoid the C++ mangling errors caused by D's built-in `T[]` slices. I have no use for overriding AST nodes, but the ability to use `extern(D)` visitors with dmd-as-a-library would be a welcome improvement. [1]: https://code.dlang.org/packages/dmdtags [2]: https://github.com/pbackus/dmdtags/blob/v1.1.1/src/dmdtags/span.d [3]: https://github.com/pbackus/dmdtags/blob/v1.1.1/src/dmdtags/appender.d I have already brought that up to one of our work group meetings regarding dmd as a library as I have stumbled upon this also. We have a solution for this, I'm going to try to implement it this week. RazvanN
