On Wed, 19 Mar 2025 at 12:31, Jonathan M Davis via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Tuesday, March 18, 2025 8:18:13 PM MDT Meta via Digitalmars-d wrote:
> > "This language is garbage collected, and they're fucking ashamed of that!"
> >
> > This guy is surprisingly perceptive and 100% accurate with his cutting observations hahaha.
>
> Plenty of us aren't (in fact, personally, I'd never have gotten into D if
> it
> didn't have a GC), but it certainly comes across that way a lot of the time
> because of attempts to make the folks happy who don't want the GC. IMHO,
> while being able to do stuff without using the GC is great, we've harmed
> ourselves by continually trying to make C/C++ people who hate the GC happy
> with D. And we keep getting into arguments about how to do stuff because
> there's a divide between those folks who are happy that D has a GC and
> those
> who don't want anything to do with the GC. The result is kind of
> schizophrenic.
>
> - Jonathan M Davis
>

We should have a 2-tier system, low-level functions to do the work which
don't enforce a particular runtime ecosystem, and then some helpful
wrappers that add convenience for scripting.
I reckon a similar and probably bigger problem for phobos though is the
template over-application and bloat. That should be addressed in the same
stroke with a low-level implementation; effort should be made to minimise
template args, and then all the high-level template-ey stuff that does all
sorts of adaptation should be in the higher level.
I never want to see 8 different copies of a function because it's called
with byte,ubyte,short,ushort,int,uint,long,ulong... where one opcode is
different because it performed a different width sign-extension, and where
the sign-extension should have been performed by the calling code anyway!
Phobos is lousy with this sort of problem, and the binaries it produces are
orders of magnitude bigger than they should be a lot of the time. Very
aggressive optimisation might fix it, but it's basically just random chance
as to whether optimisation will successfully collapse some insane code down
to something appropriate or not.

On Wednesday, 19 March 2025 at 07:17:37 UTC, Manu wrote:
> On Wed, 19 Mar 2025 at 16:41, Meta via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
> Literally every single person that has ever tried to use ImportC instantly
> complained that it doesn't import .h files. There's no reason not to merge
> his patch.
> There's been lots of discussion about this, and it seems that Walter just
> has some arbitrary opinion that it shouldn't work.
> What Walter wants you to do is write a one-line .c file somewhere in your
> source tree, with `#include "the_header.h"`; completely pointless exercise,
> and as this guy points out, it breaks the cool tech-demo and instantly
> converts every person that touches this from "WOW!" to "WTF?!"... def
> should fix this.

Just from this video alone, I completely agree with you.

To Walter: whatever technical reasons you might have for not accepting .h files, I recommend you watch the video for 10 minutes or so, starting at this timestamp:

https://youtu.be/Gj5310KnUTQ?si=ObpRmsHQO96oCpO8&t=55m27s

This shows you how close D is to really blowing people away with ImportC, and how much friction is introduced by not allowing .h files. From a marketing/first impressions perspective, it's a no brainer in my opinion.

The "wow!" factor of being able to download a big, well-known C library like Raylib and simply do `import raylib` (plus linker flags) and start using it in your D code is huge.

On Wednesday, March 19, 2025 12:05:24 AM MDT Manu via Digitalmars-d wrote:
> Why didn't his operator overloading experiment work?
>
> struct S {
>     int x;
> }
>
> // non-member opBinary
> S opBinary(string s : "+")(S lh, S rh) {
>     return S(lh.x + rh.x);
> }
>
> void main()
> {
>     S a, b;
>     S s1 = a.opBinary!"+"(b); // <- UFCS works, as expected
>     S s2 = a + b; // ERROR: doesn't work! why not? the rewrite should work
> via UFCS as above...
> }
>
> I can't imagine any good reason his experiment should have failed. I would want this too when extern to a C lib; it hasn't come up for me before, but if it did, I would log a bug instantly.

It's because the only way that you can overload operators is on the type itself. If you could do it with free functions, then we'd get the mess of operators working or not based on which modules you happened to import, and there's no way to deal with symbol conflicts, because you're not directly calling the function but instead are triggering it via a lowering that transforms then syntax into a function call. opDispatch in particular would be a total mess with such a scheme.

Either way, an enhancement request was created for it ages ago:

https://github.com/dlang/dmd/issues/18543

- Jonathan M Davis

On Wednesday, 19 March 2025 at 06:05:24 UTC, Manu wrote:

>
> I can't imagine any good reason his experiment should have failed. I would want this too when extern to a C lib; it hasn't come up for me before, but if it did, I would log a bug instantly.

That's been argued to death, too: https://forum.dlang.org/thread/ikyhbvwfekhdfrmqujxg@forum.dlang.org.