On 28/03/2025 8:17 AM, Meta wrote:
> On Thursday, 27 March 2025 at 14:06:43 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> On 28/03/2025 2:58 AM, Mike Shah wrote:
>>> betterC if I recall/inferred was somewhat a marketing term for the flag. '-no-runtime' is essentially what it does and indeed probably a better name.
>>
>> To be more exact, it is a marketing term for a collection of switches, only one of which is turning off linking against druntime.
> 
> What are the other switches? I thought the only thing -betterC does is forego linking druntime.

Here is what it does for dmd: https://github.com/dlang/dmd/blob/21cfefc9d1657207bd2ee26cfbc490de3b5a4e6b/compiler/src/dmd/main.d#L1108

While these may appear to be the consequence of not having the druntime linked in, you may for whatever reason choose to turn these off and still have druntime, or link against a different runtime.

It may be appear simple, but its actually a big bundle of codegen and linker related stuff combined together for one feature that individually can be split off like gdc does.

But you can do symmetric operations with member operator overloading in D!

On 3/27/25 21:25, Walter Bright wrote:
> On 3/18/2025 11:05 PM, Manu wrote:
>> I can't imagine any good reason his experiment should have failed.
> 
> My experience with C++ and Koenig lookup heavily influenced this.
> 
> It looks nice in simple examples, but nobody stops with simple examples. Impenetrable code is the result.
> 
> Operator overloading should be part of the type, not standalone coming from somewhere else.
> 

D has no Koenig lookup. D will never have Koenig lookup. Koenig lookup is utterly irrelevant in this discussion.

There really ought not be any important difference between:

a + b

and

a.opBinary!"+"(b)

One is just supposed to be syntactic sugar for the other. The documentation states as much.

On 3/28/25 23:51, user1234 wrote:
> On Thursday, 27 March 2025 at 22:04:53 UTC, sfp wrote:
>>
>> I'd like to understand what impediment there is to having "free" operator overloading.
> 
> 1/ A random public import in an dependency chain you dont master may unexpectedly change the expected behavior. Think to what's defined in a DUB package for example.
> ...

The situation is the same as with any UFCS call...

> 2/ Costly for a compiler. The compiler needs in each scope to have a list of opovers.

No, it does not have to do that.

On Friday, 28 March 2025 at 19:37:01 UTC, Walter Bright wrote:
> But you can do symmetric operations with member operator overloading in D!

Walter, nice to meet you last night!

Yes, you can---I explain in excruciating detail in my lengthy post why doing so sucks.

On Friday, 28 March 2025 at 23:07:24 UTC, Timon Gehr wrote:
> On 3/28/25 23:51, user1234 wrote:
>> On Thursday, 27 March 2025 at 22:04:53 UTC, sfp wrote:
>>>
>>> I'd like to understand what impediment there is to having "free" operator overloading.
>> 
>> 1/ A random public import in an dependency chain you dont master may unexpectedly change the expected behavior. Think to what's defined in a DUB package for example.
>> ...
>
> The situation is the same as with any UFCS call...

I dont see how UFCS can break my Int24 that defines opBinary!"+".

However I think you get the idea, that it not break the semantics of certains operators, especially for built-in types.

>
>> 2/ Costly for a compiler. The compiler needs in each scope to have a list of opovers.
>
> No, it does not have to do that.

I admit that there are maybe other ways to do that. I thought to lists or maps initially.

On Saturday, 29 March 2025 at 00:29:27 UTC, user1234 wrote:
> opBinary!"+".
>
> However I think you get the idea, that it not break the semantics of certains operators, especially for built-in types.

That just poped in my mind but let's say you want free standing opovers then you probably also need a way to say "dont ever overload this operation". A `@final` thing you see.

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.