On 06/03/2022 12:23 AM, rempas wrote:
> Am I the only one that things this way? If I'm not wrong, other than some (mostly runtime) advantages that "betterC" offers, It is also necessary when someone wants to allow their library to generate binding for other languages.

Its certainly a more unique way of thinking.

After all, why would you lose function overloading for no good reason?

Not to mention, now if you build your code as -betterC, but use it in a non-betterC program, boom linker errors due to mismatching mangling.

On Saturday, 5 March 2022 at 11:23:05 UTC, rempas wrote:
> Am I the only one that things this way? If I'm not wrong, other than some (mostly runtime) advantages that "betterC" offers

There's no benefit to using extern(C). Why would you want it?

> is also necessary when someone wants to allow their library to generate binding for other languages.

This is the *only* reason to use it and this is the same with and without betterC.

On Saturday, 5 March 2022 at 11:52:04 UTC, Adam D Ruppe wrote:
> On Saturday, 5 March 2022 at 11:23:05 UTC, rempas wrote:
>> Am I the only one that things this way? If I'm not wrong, other than some (mostly runtime) advantages that "betterC" offers
>
> There's no benefit to using extern(C). Why would you want it?
>
>> is also necessary when someone wants to allow their library to generate binding for other languages.
>
> This is the *only* reason to use it and this is the same with and without betterC.


There is if you want your code to be used within a C project, or any other languages that has C FFI (C#, Rust, Swift, GO to some extent)

Better C is very valuable, Rust has to go throught a lot just to provide similar functionality we get here

https://dev.to/dandyvica/how-to-call-rust-functions-from-c-on-linux-h37


I agree with OP, extern C should be the default in betterC mode!

On Saturday, 5 March 2022 at 11:34:34 UTC, rikki cattermole wrote:
>
> On 06/03/2022 12:23 AM, rempas wrote:
>> Am I the only one that things this way? If I'm not wrong, other than some (mostly runtime) advantages that "betterC" offers, It is also necessary when someone wants to allow their library to generate binding for other languages.
>
> Its certainly a more unique way of thinking.
>
> After all, why would you lose function overloading for no good reason?
>
> Not to mention, now if you build your code as -betterC, but use it in a non-betterC program, boom linker errors due to mismatching mangling.

I misread rikki's comment

Loosing function overloading is indeed problematic, so it's not a so good idea..

On Saturday, 5 March 2022 at 12:32:46 UTC, meta wrote:
> There is if you want your code to be used within a C project

I said you use it for the bindings. You should only extern(C) the necessary interface, not the whole thing.

Even in C, the recommendation is to make things `static` since not everything should be extern(C) even there! lol

> Better C is very valuable, Rust has to go throught a lot just to provide similar functionality we get here

betterC has nothing to do with C interop.

On Saturday, 5 March 2022 at 11:34:34 UTC, rikki cattermole wrote:
>
> Its certainly a more unique way of thinking.
>
> After all, why would you lose function overloading for no good reason?
>
> Not to mention, now if you build your code as -betterC, but use it in a non-betterC program, boom linker errors due to mismatching mangling.

Well, actually I didn't thought about that. Yeah, we need a way to show the linkage in the module so the import system won't fail. In that case, we either forget what I said or we need to also implement something like "extern(C) import module_name".

On Saturday, 5 March 2022 at 11:52:04 UTC, Adam D Ruppe wrote:
>
> There's no benefit to using extern(C). Why would you want it?

I said advantages (but should have said "benefits" instead as you do) of using "betterC", not "extern(C)".

> This is the *only* reason to use it and this is the same with and without betterC.

Right, I just said that probably someone will use "extern(C)" if they also use "betterC".

On Saturday, 5 March 2022 at 12:34:20 UTC, meta wrote:
> I misread rikki's comment
>
> Loosing function overloading is indeed problematic, so it's not a so good idea..

You will lose function overloading anyway if you want to export you binding to the "C" way of mangling symbols (which is not mangling them at all). So if you want to have your library used from other languages without any more effort, you won't use function overloading or templates anyway!

From the other hand, you can use D linkage in these symbols and then create an "interface" (or have someone else do that for you, lol!) with C linkage symbols that will call the overloaded functions or the template symbols. This is how I would do it!

The problem to my original post is that like Rikki said, it would be hard to make "extern(C)" the default without also modifying the module system.