On 3/19/2025 5:44 PM, matheus wrote:
> Remember Scott Meyers? Maybe invite him to the DConf?

He has done a keynote in the past.

On 3/27/2025 10:16 AM, Derek Fawcus wrote:
> Even then I came across bits where I concluded I had to manually access stuff via C, and then had to battle things - some of the stdargs/varargs bits I ran in to.

I am not aware of any issues using stdargs/varargs with betterC?

On Saturday, 29 March 2025 at 03:32:33 UTC, Walter Bright wrote:
> On 3/27/2025 10:16 AM, Derek Fawcus wrote:
>> Even then I came across bits where I concluded I had to manually access stuff via C, and then had to battle things - some of the stdargs/varargs bits I ran in to.
>
> I am not aware of any issues using stdargs/varargs with betterC?

Originally reported in the bug tracker on 14th October:
   https://issues.dlang.org/show_bug.cgi?id=24814

Now tracked in an issue following migration:
   https://github.com/dlang/dmd/issues/20534

It relates to the fact that for x86-64 use of DMD, the va_copy/va_end facilities need to use alloca(), and the latter fails under betterC.  The latter also has its own bug:

   https://issues.dlang.org/show_bug.cgi?id=24815
   https://github.com/dlang/dmd/issues/18276

I had included a partial fix for the first issue, and the patch is also attached to the github issue.  More details are in the original bug ticket, and the thread it links to.

On 29/03/2025 4:27 PM, Walter Bright wrote:
> On 3/25/2025 4:19 AM, Mike Shah wrote:
>> Indeed, I wrote my own 'DynArray' type for use in betterC. Declaration is with 'DynArray!int intArray' for example. I then used overloads for opSlice and such to get pretty much the same functionality (e g. auto slice = intArray[2..4]). I can also wrap that with a reference counted type to help avoid leaks if lifetime and scope varies :)
> 
> Several of us studied reference counting for a while, and came to the unfortunate conclusion that is wasn't practical to make it memory safe without a GC or a borrow checker. Ref counting also has performance issues.
> 
> (Holding a non-refcounted reference to the payload of a refcounted object runs the risk of becoming a dangling pointer, but if that is disallowed, performance problems ensue.)
> 
> I use allocated slices all the time that don't use the GC, but I take care to manage the memory manually.

There is only two solutions that I've come up with that solves this:

1. Have a proper DFA solution to escape analysis
2. Disable any action that can lead to borrowing

For system handles both work fine, and the second is needed for the first anyway.

And as Walter knows, I've been hammering on the DFA language features stuff for a while pretty heavily. I'm waiting on an update to see what I need to do next for him.

On Saturday, 29 March 2025 at 11:50:58 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 29/03/2025 4:27 PM, Walter Bright wrote:
>> On 3/25/2025 4:19 AM, Mike Shah wrote:
>>> Indeed, I wrote my own 'DynArray' type for use in betterC. Declaration is with 'DynArray!int intArray' for example. I then used overloads for opSlice and such to get pretty much the same functionality (e g. auto slice = intArray[2..4]). I can also wrap that with a reference counted type to help avoid leaks if lifetime and scope varies :)
>> 
>> Several of us studied reference counting for a while, and came to the unfortunate conclusion that is wasn't practical to make it memory safe without a GC or a borrow checker. Ref counting also has performance issues.
>> 
>> (Holding a non-refcounted reference to the payload of a refcounted object runs the risk of becoming a dangling pointer, but if that is disallowed, performance problems ensue.)
>> 
>> I use allocated slices all the time that don't use the GC, but I take care to manage the memory manually.
>
> There is only two solutions that I've come up with that solves this:
>
> 1. Have a proper DFA solution to escape analysis
> 2. Disable any action that can lead to borrowing
>
> For system handles both work fine, and the second is needed for the first anyway.
>
> And as Walter knows, I've been hammering on the DFA language features stuff for a while pretty heavily. I'm waiting on an update to see what I need to do next for him.

Indeed an escape analysis or borrow checker is the way to go, or otherwise manually managing the memory when it comes to performance.

I also have run into problems with ref counting (in C++ for example with std::shared_ptr) in regards to the control block that stores the ref count that needs to be atomically incremented when used with a multithreaded program.

On 3/29/25 01:17, Dennis wrote:
> On Thursday, 27 March 2025 at 22:04:53 UTC, sfp wrote:
>> A way around this problem that does work but isn't particularly satisfying is to kiss operator overloading goodbye. Just use `mul` for matrix multiplication. There's a good chance this is what I'll end up having to do.
> 
> As a workaround, have you considered making operator overload members forward to one generic function?
> 
> ```
> auto opBinary(string op : "*", T)(T other) => mul(this, other);
> ```
> 
> That's O(n) boilerplate, as opposed to O(n^2) opBinary implementations.

Well, your type may be compatible with some built-in types as well, so you also need opBinaryRight. And then when you have multiple types that use this strategy, you have to break the symmetry somehow to avoid ambiguity errors. Furthermore, now the type's module has to import every operator implementation you ever want to use.

This all seems a bit much to ask for the convenience of using the standard operator notation for your calls to mathematical functions.