www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Tsoding streamed about D

reply Maximilian Naderer <maximilian.wallinger outlook.com> writes:
Hello guys,

Not sure if you are aware a pretty big Streamer made a video 
about D!

Not that it’s important for me but he is really impressed with 
the language and was blown away a couple of times.

https://youtu.be/Gj5310KnUTQ?si=rSP50Uf9oeb4vLm1

Best regards,
Max
Mar 18
next sibling parent reply Adam Wilson <flyboynw gmail.com> writes:
On Tuesday, 18 March 2025 at 20:00:01 UTC, Maximilian Naderer 
wrote:

 Hello guys,

 Not sure if you are aware a pretty big Streamer made a video 
 about D!

 Not that it’s important for me but he is really impressed with 
 the language and was blown away a couple of times.

 https://youtu.be/Gj5310KnUTQ?si=rSP50Uf9oeb4vLm1

 Best regards,
 Max


It's a refreshingly honest take. We aren't perfect and I doubt 
he'll become a D-promoter, but the fact that we were able to 
consistently surprise him, both in language and in library is a 
statement on how far we've come. I also want to note that the 
depth of the standard library was a consistent theme, and while I 
am clearly biased, I think this demonstrates again something that 
I've been saying about Phobos. People want deep standard 
libraries, they don't want to hunt through package managers for 
things that are considered basic/standard. The fact that we 
provided much more than he expected worked in D's favor.
Mar 18
next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Tuesday, 18 March 2025 at 23:12:58 UTC, Adam Wilson wrote:

snip


 I think this demonstrates again something that I've been saying 
 about Phobos. People want deep standard libraries, they don't 
 want to hunt through package managers for things that are 
 considered basic/standard. The fact that we provided much more 
 than he expected worked in D's favor.


Well said Adam, +1!
Mar 18
prev sibling parent reply Lance Bachmeier <no spam.net> writes:
On Tuesday, 18 March 2025 at 23:12:58 UTC, Adam Wilson wrote:


 It's a refreshingly honest take. We aren't perfect and I doubt 
 he'll become a D-promoter, but the fact that we were able to 
 consistently surprise him, both in language and in library is a 
 statement on how far we've come.


There is too much negativity among D users for the most part. 
There are lots of problems, but that applies to every language.


 I also want to note that the depth of the standard library was 
 a consistent theme, and while I am clearly biased, I think this 
 demonstrates again something that I've been saying about 
 Phobos. People want deep standard libraries, they don't want to 
 hunt through package managers for things that are considered 
 basic/standard. The fact that we provided much more than he 
 expected worked in D's favor.


I've been hearing for a long time we should have a small standard 
library. I've never understood the argument.
Mar 18
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/18/2025 7:32 PM, Lance Bachmeier wrote:

 There is too much negativity among D users for the most part. There are lots
of 
 problems, but that applies to every language.


What's important is can one code a solution quickly and it be more likely to 
work, be bug-free, and readable.
Mar 27
prev sibling next sibling parent reply Meta <jared771 gmail.com> writes:
On Tuesday, 18 March 2025 at 20:00:01 UTC, Maximilian Naderer 
wrote:

 Hello guys,

 Not sure if you are aware a pretty big Streamer made a video 
 about D!

 Not that it’s important for me but he is really impressed with 
 the language and was blown away a couple of times.

 https://youtu.be/Gj5310KnUTQ?si=rSP50Uf9oeb4vLm1

 Best regards,
 Max


"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.
Mar 18
next sibling parent reply Manu <turkeyman gmail.com> writes:
On Wed, 19 Mar 2025 at 11:36, Meta via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Tuesday, 18 March 2025 at 20:00:01 UTC, Maximilian Naderer
 wrote:

 Hello guys,

 Not sure if you are aware a pretty big Streamer made a video
 about D!

 Not that it=E2=80=99s important for me but he is really impressed with
 the language and was blown away a couple of times.

 https://youtu.be/Gj5310KnUTQ?si=3DrSP50Uf9oeb4vLm1

 Best regards,
 Max


 "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.


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 =3D a.opBinary!"+"(b); // <- UFCS works, as expected
    S s2 =3D a + b; // ERROR: doesn't work! why not? the rewrite should wor=
k
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.
Mar 18
next sibling parent reply Meta <jared771 gmail.com> writes:
On Wednesday, 19 March 2025 at 06:05:24 UTC, Manu wrote:

 On Wed, 19 Mar 2025 at 11:36, Meta via Digitalmars-d < 
 digitalmars-d puremagic.com> 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.


 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 don't know the specific compiler details, but you make a good 
point that this _should_ work via UFCS. Probably the compiler 
first checks that it's a member function or something.


 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.


Yeah, I've always wanted free-standing operator overload 
functions in D, and I think the case for them has only gotten 
stronger with better C and C++ integration, and _especially_ with 
ImportC.

His other main gripe was that the compiler rejects .h files, even 
though when he changed the extension to .c, it compiled and ran 
just fine. In the footnote section he actually downloads the 
source code and modifies it to compile .h files, and it's a 
surprisingly simple change. I wonder if there's a specific reason 
Walter didn't allow it.
Mar 18
next sibling parent reply Manu <turkeyman gmail.com> writes:
On Wed, 19 Mar 2025 at 16:41, Meta via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


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

 On Wed, 19 Mar 2025 at 11:36, Meta via Digitalmars-d <
 digitalmars-d puremagic.com> 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.


 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 don't know the specific compiler details, but you make a good
 point that this _should_ work via UFCS. Probably the compiler
 first checks that it's a member function or something.


 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.


 Yeah, I've always wanted free-standing operator overload
 functions in D, and I think the case for them has only gotten
 stronger with better C and C++ integration, and _especially_ with
 ImportC.

 His other main gripe was that the compiler rejects .h files, even
 though when he changed the extension to .c, it compiled and ran
 just fine. In the footnote section he actually downloads the
 source code and modifies it to compile .h files, and it's a
 surprisingly simple change. I wonder if there's a specific reason
 Walter didn't allow it.


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.
Mar 19
next sibling parent reply Meta <jared771 gmail.com> writes:
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.
Mar 19
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 19 March 2025 at 07:54:43 UTC, Meta wrote:

 On Wednesday, 19 March 2025 at 07:17:37 UTC, Manu wrote:

 [...]


 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.


I don’t think Walter was the bottleneck on the .h .c issue. The 
problem was that it was breaking code in the other compilers.
Mar 19
parent Manu <turkeyman gmail.com> writes:
Wed, 19 Mar 2025 at 21:25, jmh530 via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Wednesday, 19 March 2025 at 07:54:43 UTC, Meta wrote:

 On Wednesday, 19 March 2025 at 07:17:37 UTC, Manu wrote:

 [...]


 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=3DObpRmsHQO96oCpO8&t=3D55m27s

 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.


 I don=E2=80=99t think Walter was the bottleneck on the .h .c issue. The
 problem was that it was breaking code in the other compilers.


How so? I don't remember anything on that matter.
Mar 19
prev sibling next sibling parent reply Lance Bachmeier <no spam.net> writes:
On Wednesday, 19 March 2025 at 07:54:43 UTC, Meta wrote:


 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:


You can't blame Walter for this one. He opened the bug report to 
enable it! It was others that killed it: 
https://github.com/dlang/dmd/issues/20184
Mar 19
next sibling parent Lance Bachmeier <no spam.net> writes:
On Wednesday, 19 March 2025 at 11:32:01 UTC, Lance Bachmeier 
wrote:

 On Wednesday, 19 March 2025 at 07:54:43 UTC, Meta wrote:


 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:


 You can't blame Walter for this one. He opened the bug report 
 to enable it! It was others that killed it: 
 https://github.com/dlang/dmd/issues/20184


This is the first time I'm seeing Walter's proposal to use 
`-revert=hfiles`. He's absolutely right on that.
Mar 19
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On Wed, 19 Mar 2025 at 21:36, Lance Bachmeier via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Wednesday, 19 March 2025 at 07:54:43 UTC, Meta wrote:


 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:


 You can't blame Walter for this one. He opened the bug report to
 enable it! It was others that killed it:
 https://github.com/dlang/dmd/issues/20184


Sorry Walter, I apologise.
I just recall him giving detailed usage explanations including to make a
1-line .c file as if that was a cool and intended design... and this was
always in response to complaints that it didn't import .h files.
Mar 19
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/19/2025 6:16 AM, Manu wrote:

 Sorry Walter, I apologise.


Accepted. Thank you! -Walter
Mar 27
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Wednesday, 19 March 2025 at 11:32:01 UTC, Lance Bachmeier 
wrote:

 On Wednesday, 19 March 2025 at 07:54:43 UTC, Meta wrote:


 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:


 You can't blame Walter for this one. He opened the bug report 
 to enable it! It was others that killed it: 
 https://github.com/dlang/dmd/issues/20184


Looking at https://github.com/dlang/dmd/pull/14864, it seems that 
the changes to load .h files broke gdc, because it has a lot of 
auto-generated headers that - with Walter's change - were getting 
preferred over .d files if they were found first when doing 
`import x`, which x being a name that matched the name of the 
header file. Thus his change got reverted (rightly so, IMO; a D 
compiler that prefers to import .h files over .d files in certain 
circumstances is just weird).

Then Iain submitted another PR to reapply Walter's original 
changes, but it was slightly different and did something that 
Walter didn't like, so he reverted it.

After a bunch of arguing and different proposals rejected, it 
looks like things came to an impasse and so the issue was just 
left unadressed.

Plenty of blame to go around.
Mar 19
next sibling parent Derek Fawcus <dfawcus+dlang employees.org> writes:
On Wednesday, 19 March 2025 at 15:36:56 UTC, Meta wrote:

 After a bunch of arguing and different proposals rejected, it 
 looks like things came to an impasse and so the issue was just 
 left unadressed.

 Plenty of blame to go around.


I possibly should have posted 
[this](https://forum.dlang.org/post/hppmtcrgmyqxqlebyhai forum.dlang.org) here.
Mar 24
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/19/2025 8:36 AM, Meta wrote:

 (rightly so, IMO; a D compiler that 
 prefers to import .h files over .d files in certain circumstances is just
weird).


"Header" files are preferred over "Implementation" files.
Mar 27
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/19/2025 12:54 AM, Meta wrote:

 To Walter: whatever technical reasons you might have for not accepting .h
files, 


I'm well aware of this.
Mar 27
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
I'll let the PR and the followup PRs speak for themselves:

https://github.com/dlang/dmd/pull/14636
Mar 27
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/19/2025 12:17 AM, Manu 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.


Iain reverted my change to import .h files. We did not reach an agreement. The 
debate is in the git history.
Mar 27
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/18/2025 11:36 PM, Meta wrote:

 His other main gripe was that the compiler rejects .h files, even though when
he 
 changed the extension to .c, it compiled and ran just fine. In the footnote 
 section he actually downloads the source code and modifies it to compile .h 
 files, and it's a surprisingly simple change. I wonder if there's a specific 
 reason Walter didn't allow it.


The reason is Iain didn't like it because he had file.d and file.h in the same 
directory. He did implement a rather complex (in my opinion) way to
disambiguate 
it, and I preferred simply having an order. We did not reach an agreement, and 
so .h files are not considered.

Is this stupid? Yes.
Mar 27
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On Thursday, 27 March 2025 at 20:01:41 UTC, Walter Bright wrote:


 The reason is Iain didn't like it because he had file.d and 
 file.h in the same directory.


This is not true.


 Is this stupid? Yes.


I agree. Try to understand the problem and we can come up with a 
solution. I proposed one too.

But without understanding the problem you’ll never get traction.

-Steve
Mar 27
prev sibling next sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Wednesday, 19 March 2025 at 06:05:24 UTC, Manu wrote:

 On Wed, 19 Mar 2025 at 11:36, Meta via Digitalmars-d < 
 digitalmars-d puremagic.com> wrote:


 On Tuesday, 18 March 2025 at 20:00:01 UTC, Maximilian Naderer 
 wrote:

 Hello guys,

 Not sure if you are aware a pretty big Streamer made a video 
 about D!

 Not that it’s important for me but he is really impressed 
 with the language and was blown away a couple of times.

 https://youtu.be/Gj5310KnUTQ?si=rSP50Uf9oeb4vLm1

 Best regards,
 Max


 "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.


 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.


https://forum.dlang.org/thread/iyqxqqvnmhegigxlpjcx forum.dlang.org
Mar 19
prev sibling next sibling parent Max Samukha <maxsamukha gmail.com> writes:
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.
Mar 19
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Wednesday, 19 March 2025 at 06:05:24 UTC, Manu wrote:

 On Wed, 19 Mar 2025 at 11:36, Meta via Digitalmars-d < 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.


operator overloads must be member functions.

I think this fits into Walter's vision that you should not be 
able to abuse operator overloads to build your own semantics with 
already-defined types.

e.g. you shouldn't be able to define `a + b` to be something 
other than what `a` or `b` intended.

This already is allowed via UFCS, I guess Walter thinks operator 
overloads are more intimate for the types.

Take note that UFCS did not exist for D1 ([except for 
arrays](https://digitalmars.com/d/1.0/arrays.html#func-as-property)), so this
vision was more consistent back then.

I don't know if this is one of those "will never happen" stances, 
or "maybe I can be convinced" stances.

-Steve
Mar 19
parent reply Ogion <ogion.art gmail.com> writes:
On Wednesday, 19 March 2025 at 11:37:21 UTC, Steven Schveighoffer 
wrote:

 e.g. you shouldn't be able to define `a + b` to be something 
 other than what `a` or `b` intended.


My first thought was, why would anyone do such an evil thing. 
Then I realized how tempting it would be to circumvent integer 
promotion rules with operator overloading…

“With that power I should have power too great and terrible. And 
over me the Ring would gain a power still greater and more 
deadly.”
Mar 19
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/19/2025 6:20 AM, Ogion wrote:

 “With that power I should have power too great and terrible. And over me the 
 Ring would gain a power still greater and more deadly.”


Koenig Lookup (officially known as ADL, Argument Dependent Lookup) is a
terrible 
thing. Even Andrew Koenig was unhappy his name was associated with it.

I've seen the destruction that ADL hath wrought. It's similar to the horrors 
that macros inevitably spawn. Although hobbits are resistant to its evil 
influence, I haven't met any hobbitses yet. Just too many Boromirs.

D originally was not going to have operator overloading at all because of that, 
but eventually it was added, but heavily restricted compared with C++.
Mar 27
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Mar 27
next sibling parent reply sfp <sfp hush.ai> writes:
On Thursday, 27 March 2025 at 20:25:52 UTC, 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.


I'd like to understand what impediment there is to having "free" 
operator overloading.

It seems like once the code has been parsed/whatever, you should 
have "canonicalized" the operator syntax into some function call. 
At that point what difference does it make whether the operator 
was defined as a free function or member function? Basically, why 
would "UFCS" not also work for the canonicalized names for 
overloaded operators?

I write mathematical software for a living and forcing operators 
to be member functions sucks for me. This feature is important to 
me, so I'll try to spell this out a little bit. I realize that my 
opinion on its own doesn't carry a ton of weight; but, on the off 
chance that the main reason this feature hasn't been implemented 
is aesthetic rather than technical, I'd like to say my bit. ;-)

Main problem is that in mathematical software you want to be able 
to implement symmetric operations, and oftentimes doing this 
correctly requires double or multiple dispatch. The classic 
example is a small linear algebra with specialized types for 
different kinds of matrices.

Let's say I have a `DenseMatrix` type and a `SparseMatrix` type; 
and, who knows, maybe an `IdentityMatrix` type. If I want to 
implement a binary operation like matrix multiplication, it 
really is nice to use operator overloading for this. Maybe the 
best case scenario for the prospecting D user is doing something 
like what Eigen (a C++ template linear algebra library) does and 
lean on static polymorphism. But now I need to stick a separate 
`opBinary!"*"` on each type. As the number of types grows this 
gets significantly less maintainable. If I could define an 
operator as a free function I could lean on D's amazing 
metaprogramming capabilities and simplify my code, make it 
shorter, more maintainable, etc, etc. And, speaking from my own 
experience at least, this is not an insignificant or imagined 
benefit.

Actually, whether static polymorphism and the whole Eigen concept 
makes sense is totally debatable (at least for Eigen, the runtime 
efficiency gained by expression templates is completely obviated 
by the insane compile times... but this is a C++ library...). In 
many cases runtime polymorphism may be preferable. Unfortunately, 
D's `class` is straight out since it doesn't support multiple 
dispatch. And, anyway, the same issue discussed in the previous 
paragraph persists. A way to get around this is to use 
metaprogramming and `struct` to build up bespoke "interface" 
types that *do* support multiple dispatch (which is what I'm 
doing... -_-), but... well, I'll just say this also runs into 
trouble with non-free operator definitions.

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.

And, in fact, I've already done it for other mathematical 
operations. I have a `ccomb(x, y, t)` function which computes the 
convex combination `(1 - t)*x + t*y` for a wide variety of types 
(standard types, arbitrary precision rationals, intervals, 
vectors, whatever). Initially, I had this function defined in the 
module of each type I wanted it defined for, but it ended up 
being simpler and more natural to just define a new module 
`ccomb.d` containing all those definitions... not unlike what is 
done in MATLAB! The function `ccomb` is symmetric in `x` and `y` 
and a good implementation of it also *wants* to be symmetric. 
This symmetry would be extremely difficult to obtain if `ccomb` 
were forced to be a member function.

Maybe you can see where I'm going with this... I don't see why 
the functions defining operators should be treated any 
differently!
Mar 27
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
But you can do symmetric operations with member operator overloading in D!
Mar 28
parent sfp <sfp hush.ai> writes:
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.
Mar 28
prev sibling next sibling parent reply user1234 <user1234 12.fr> writes:
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.

2/ Costly for a compiler. The compiler needs in each scope to 
have a list of opovers.
Mar 28
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Mar 28
parent reply user1234 <user1234 12.fr> writes:
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.
Mar 28
parent user1234 <user1234 12.fr> writes:
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.
Mar 28
prev sibling parent reply Dennis <dkorpel gmail.com> writes:
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.
Mar 28
parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Mar 29
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Mar 28
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Mar 19
prev sibling next sibling parent Meta <jared771 gmail.com> writes:
On Tuesday, 18 March 2025 at 20:00:01 UTC, Maximilian Naderer 
wrote:

 Hello guys,

 Not sure if you are aware a pretty big Streamer made a video 
 about D!

 Not that it’s important for me but he is really impressed with 
 the language and was blown away a couple of times.

 https://youtu.be/Gj5310KnUTQ?si=rSP50Uf9oeb4vLm1

 Best regards,
 Max


"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.
Mar 18
prev sibling next sibling parent reply Meta <jared771 gmail.com> writes:
On Tuesday, 18 March 2025 at 20:00:01 UTC, Maximilian Naderer 
wrote:

 Hello guys,

 Not sure if you are aware a pretty big Streamer made a video 
 about D!

 Not that it’s important for me but he is really impressed with 
 the language and was blown away a couple of times.

 https://youtu.be/Gj5310KnUTQ?si=rSP50Uf9oeb4vLm1

 Best regards,
 Max


"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.
Mar 18
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Mar 18
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 19 March 2025 at 02:29:00 UTC, Jonathan M Davis 
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



professionally, Go occasionally even if not freely, and love the 
work being done in Swift, Chapel, Linear Haskell, OCaml effects, 
Idris, Dafny, FStar....

Alongside all those folks that aren't asking for forgiveness 
selling selling bare metal managed IoT platforms.

What D has missed versus those other ecosystems, is drawing the 
line that if that isn't what someone is looking for in a 
language, they can gladly look elsewhere, thus the schizophrenic 
outcome.
Mar 19
next sibling parent reply Guillaume Piolat <first.nam_e gmail.com> writes:
On Wednesday, 19 March 2025 at 12:56:04 UTC, Paulo Pinto wrote:

 What D has missed versus those other ecosystems, is drawing the 
 line that if that isn't what someone is looking for in a 
 language, they can gladly look elsewhere, thus the 
 schizophrenic outcome.


Disagree, D is the a language that "doesn't get in the way" 
precisely because it gives a lot of choice to users.

Tsoding being able to work roughly like he's accustomed in C with 
a lot of familiarity, implementing his favourite pattern then 
modifying the compiler in less than 2 hours, is precisely because 
D isn't very prescriptive.

Yes there are two ways to do a lot of things (polymorphism, 
errors, aggregates, memory management) but this is precisely the 
point no?
Mar 19
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 19 March 2025 at 13:18:57 UTC, Guillaume Piolat 
wrote:

 On Wednesday, 19 March 2025 at 12:56:04 UTC, Paulo Pinto wrote:

 What D has missed versus those other ecosystems, is drawing 
 the line that if that isn't what someone is looking for in a 
 language, they can gladly look elsewhere, thus the 
 schizophrenic outcome.


 Disagree, D is the a language that "doesn't get in the way" 
 precisely because it gives a lot of choice to users.

 Tsoding being able to work roughly like he's accustomed in C 
 with a lot of familiarity, implementing his favourite pattern 
 then modifying the compiler in less than 2 hours, is precisely 
 because D isn't very prescriptive.

 Yes there are two ways to do a lot of things (polymorphism, 
 errors, aggregates, memory management) but this is precisely 
 the point no?


How helpful has that been regarding adoption, versus the other 
ecosystems that do draw the line?
Mar 19
parent reply Guillaume Piolat <first.nam_e gmail.com> writes:
On Wednesday, 19 March 2025 at 13:55:57 UTC, Paulo Pinto wrote:

 How helpful has that been regarding adoption, versus the other 
 ecosystems that do draw the line?


Better than Idris?

Language adoption is driven by libraries not how authoritarian it 
is.

Besides there are two tier of language newly created: 
https://www.youtube.com/watch?v=XZ3w_jec1v8

It is harder for the grassroot languages that don't come from big 
businesses, to the exception of Python.
Mar 19
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 19 March 2025 at 13:58:30 UTC, Guillaume Piolat 
wrote:

 On Wednesday, 19 March 2025 at 13:55:57 UTC, Paulo Pinto wrote:

 How helpful has that been regarding adoption, versus the other 
 ecosystems that do draw the line?


 Better than Idris?

 Language adoption is driven by libraries not how authoritarian 
 it is.

 Besides there are two tier of language newly created: 
 https://www.youtube.com/watch?v=XZ3w_jec1v8

 It is harder for the grassroot languages that don't come from 
 big businesses, to the exception of Python.


Besides cherry picking, I would assert Idris might have more 
users, even if it is an academic language.

As for libraries, exactly because those languages draw the line, 
it is possible to have a library ecosystem, instead of writing 
libraries that can only be used by the GC camp, the GC but please 
in RC form camp, the we only do malloc/free came, the  nogc 
camp,...

Instead a library, regardless how it is written, works for 
everyone.
Mar 19
parent Dukc <ajieskola gmail.com> writes:
On Wednesday, 19 March 2025 at 22:59:20 UTC, Paulo Pinto wrote:

 instead of writing libraries that can only be used by the GC 
 camp, the GC but please in RC form camp, the we only do 
 malloc/free came, the  nogc camp,...


While the problem is real, it isn't like that. A ` nogc` person 
would be happy to use a "use `malloc`/`free`" - library for 
instance, and a GC person would probably use a reference counted 
object even though she might prefer a GC solution if one is there.

The only hard limit is that if you need to be (or are dogmatic 
about) ` nogc` or BetterC, then your library has to support that. 
All other limits are soft: the library might be annoying to use, 
but does the job.

It isn't much different from the divide between high-level and 
low-level functionality that is there in any language. If you're 
doing something custom at low level, only low-level library 
functions will do. If you'll stay at higher level, using a 
high-level library is usually easier but you can do with a 
lower-level library in a pinch.
Mar 20
prev sibling next sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Wednesday, 19 March 2025 at 13:18:57 UTC, Guillaume Piolat 
wrote:

 On Wednesday, 19 March 2025 at 12:56:04 UTC, Paulo Pinto wrote:

 What D has missed versus those other ecosystems, is drawing 
 the line that if that isn't what someone is looking for in a 
 language, they can gladly look elsewhere, thus the 
 schizophrenic outcome.


 Disagree, D is the a language that "doesn't get in the way" 
 precisely because it gives a lot of choice to users.

 Tsoding being able to work roughly like he's accustomed in C 
 with a lot of familiarity, implementing his favourite pattern 
 then modifying the compiler in less than 2 hours, is precisely 
 because D isn't very prescriptive.

 Yes there are two ways to do a lot of things (polymorphism, 
 errors, aggregates, memory management) but this is precisely 
 the point no?


this, D is a pragmatic language, GC was the reason i tried the 
language, and -betterC was the reason i never needed to look 
elsewhere

and now it also can compile C code.. who would have thought you 
could do so much when your focus is pragmatism

this combo is a competitive advantage many language just doesn't 
have, on top of compiling code VERY FAST

want to support WASM before everyone elses ready? you can do that 
too

the answer to "adoption" is marketing, nothing else

hey look, pragmatism is a good marketing opportunity

he said it in the video:

in D you can enable borrow checking when needed, it's better than 
Rust because it lets you experiment with your ideas first in the 
same language, Rust people experiment first with Python, then do 
the implementation in Rust, a waste of time

pragmatism is the key in a world dominated by bloatware
Mar 20
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/19/2025 6:18 AM, Guillaume Piolat wrote:

 Tsoding being able to work roughly like he's accustomed in C with a lot of 
 familiarity, implementing his favourite pattern then modifying the compiler in 
 less than 2 hours, is precisely because D isn't very prescriptive.


I'm pretty sure he worked out in advance the difficulties he'd encounter 
followed quickly by the solutions.
Mar 27
prev sibling parent reply Martyn <martyn.developer googlemail.com> writes:
On Wednesday, 19 March 2025 at 12:56:04 UTC, Paulo Pinto wrote:

 On Wednesday, 19 March 2025 at 02:29:00 UTC, Jonathan M Davis 
 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



 professionally, Go occasionally even if not freely, and love 
 the work being done in Swift, Chapel, Linear Haskell, OCaml 
 effects, Idris, Dafny, FStar....

 Alongside all those folks that aren't asking for forgiveness 
 selling selling bare metal managed IoT platforms.

 What D has missed versus those other ecosystems, is drawing the 
 line that if that isn't what someone is looking for in a 
 language, they can gladly look elsewhere, thus the 
 schizophrenic outcome.


A number of Tsodings views/rants are sprinkled with some humour. 
You could say troll-like. However, lets be honest about a few 
things :-

- Tsoding had done a bit of dlang a number of years ago but 
admitted he is likely diving in again from scratch

- Tscoding said what interested him about trying D again was 
BetterC

- Tsoding made a pretty big fuss about "BetterC disabling dynamic 
arrays" but, again, his behaviour is a mix of humour and troll as 
well.


Point is, he is going through the emotions of someone looking 
into a language that povides his needs. If he did not find out 
about BetterC, he might not have given Dlang the time of day -- 
and no stream.

You have to ask yourself WHY he came to D in the first place. He 

into GC languages like Go, he is also comftable with non-GC 
langauges as well Rust, Go, Zig, Jai, etc.

Point is - he returned to Dlang becauase D provides OPTIONS to 
the programmer. D works for programmers like Tsoding who comes 
from that C\C++ branch.

As I mentioned in an old comment, if D sets the rules or what it 
is and isn't - then it need to do so now. However, based on a few 
replies (including Walter) that is not going to happen. It 
certainly wont be in the same way as Odin who makes it clear what 
it will do and wont.

Lastly, and not aimed at Paulo, a number of us here do not hate 
the GC. I like that I have to option to enable or disable it. 
Would I prefer the GC to be handled differently? Of course... but 
we have to accept that D is a swiss army knife and opens the door 
for various types of programmers/developers in. It also opens the 
door for various querys (and rants) as well. I might have joined 
into some "rants" (if you call it that) but I also try to remain 
respectful.
Mar 24
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 25/03/2025 12:08 AM, Martyn wrote:

 Point is, he is going through the emotions of someone looking into a 
 language that povides his needs. If he did not find out about BetterC, 
 he might not have given Dlang the time of day -- and no stream.
 
 You have to ask yourself WHY he came to D in the first place. He is not 

 languages like Go, he is also comftable with non-GC langauges as well 
 Rust, Go, Zig, Jai, etc.
 
 Point is - he returned to Dlang becauase D provides OPTIONS to the 
 programmer. D works for programmers like Tsoding who comes from that 
 C\C++ branch.


How I would describe D is it scales.

If you wanna run D on a dreamcast, good for you!

If you wanna write some basic utility program great!

Where D is failing to meet the full scale is places where D must improve.
Mar 24
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On Mon, 24 Mar 2025 at 21:10, Martyn via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 - Tsoding made a pretty big fuss about "BetterC disabling dynamic
 arrays" but, again, his behaviour is a mix of humour and troll as
 well.


He probably just assumed there should be an array in the library (and he's
right to do so!). It probably didn't occur to him that things like arrays
and maps were intimately tied to the GC.
There should be containers in the library, and then we can remove that text
from the spec.
...but there's not! and there's reasons why...
Mar 24
parent reply Derek Fawcus <dfawcus+dlang employees.org> writes:
On Tuesday, 25 March 2025 at 05:19:08 UTC, Manu wrote:

 On Mon, 24 Mar 2025 at 21:10, Martyn via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:


 - Tsoding made a pretty big fuss about "BetterC disabling 
 dynamic arrays" but, again, his behaviour is a mix of humour 
 and troll as well.


 He probably just assumed there should be an array in the 
 library (and he's right to do so!). It probably didn't occur to 
 him that things like arrays and maps were intimately tied to 
 the GC.
 There should be containers in the library, and then we can 
 remove that text from the spec.
 ...but there's not! and there's reasons why...


Despite the fact that they're tied to the GC, I rather assumed 
one could create a library based version, which could preserve 
the array and slice syntax for use.  Declaration may well have to 
differ (using some form of template?)

Albeit they'd likely leak depending upon just how they were used. 
  c.f. Odin having dynamic arrays despite no GC.
Mar 25
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 25 March 2025 at 09:26:45 UTC, Derek Fawcus wrote:

 On Tuesday, 25 March 2025 at 05:19:08 UTC, Manu wrote:

 On Mon, 24 Mar 2025 at 21:10, Martyn via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:


 - Tsoding made a pretty big fuss about "BetterC disabling 
 dynamic arrays" but, again, his behaviour is a mix of humour 
 and troll as well.


 He probably just assumed there should be an array in the 
 library (and he's right to do so!). It probably didn't occur 
 to him that things like arrays and maps were intimately tied 
 to the GC.
 There should be containers in the library, and then we can 
 remove that text from the spec.
 ...but there's not! and there's reasons why...


 Despite the fact that they're tied to the GC, I rather assumed 
 one could create a library based version, which could preserve 
 the array and slice syntax for use.  Declaration may well have 
 to differ (using some form of template?)

 Albeit they'd likely leak depending upon just how they were 
 used.  c.f. Odin having dynamic arrays despite no GC.


Nothing special, after all Ada, Object Pascal/Delphi, Modula-2, 
Zig, C++ all provide them, also without GC, and without leaking 
assuming correct use, as they use the respective managed features 
available.

So indeed, there would be a way to have them without GC, but 
boils down to having multiple vocabulary types, and libraries 
needing to decide what approach to support.
Mar 25
prev sibling parent reply Mike Shah <mshah.475 gmail.com> writes:
On Tuesday, 25 March 2025 at 09:26:45 UTC, Derek Fawcus wrote:

 On Tuesday, 25 March 2025 at 05:19:08 UTC, Manu wrote:

 On Mon, 24 Mar 2025 at 21:10, Martyn via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:


 - Tsoding made a pretty big fuss about "BetterC disabling 
 dynamic arrays" but, again, his behaviour is a mix of humour 
 and troll as well.


 He probably just assumed there should be an array in the 
 library (and he's right to do so!). It probably didn't occur 
 to him that things like arrays and maps were intimately tied 
 to the GC.
 There should be containers in the library, and then we can 
 remove that text from the spec.
 ...but there's not! and there's reasons why...


 Despite the fact that they're tied to the GC, I rather assumed 
 one could create a library based version, which could preserve 
 the array and slice syntax for use.  Declaration may well have 
 to differ (using some form of template?)

 Albeit they'd likely leak depending upon just how they were 
 used.  c.f. Odin having dynamic arrays despite no GC.


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 :)
Mar 25
next sibling parent Ogion <ogion.art gmail.com> writes:
On Tuesday, 25 March 2025 at 11:19:04 UTC, 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 :)


`std.container.array` is basically this. Except it doesn’t work 
in BetterC :^)
Mar 25
prev sibling next sibling parent reply Mengu <mengukagan gmail.com> writes:
On Tuesday, 25 March 2025 at 11:19:04 UTC, Mike Shah wrote:

 On Tuesday, 25 March 2025 at 09:26:45 UTC, Derek Fawcus 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 :)


How about a session in your channel with him? :)
Mar 26
next sibling parent Sergey <kornburn yandex.ru> writes:
On Wednesday, 26 March 2025 at 15:58:54 UTC, Mengu wrote:

 On Tuesday, 25 March 2025 at 11:19:04 UTC, Mike Shah wrote:

 On Tuesday, 25 March 2025 at 09:26:45 UTC, Derek Fawcus 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 :)


 How about a session in your channel with him? :)


Nah.. tsoding is mostly a C guy
Mar 26
prev sibling parent Mike Shah <mshah.475 gmail.com> writes:
On Wednesday, 26 March 2025 at 15:58:54 UTC, Mengu wrote:

 On Tuesday, 25 March 2025 at 11:19:04 UTC, Mike Shah wrote:

 On Tuesday, 25 March 2025 at 09:26:45 UTC, Derek Fawcus 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 :)


 How about a session in your channel with him? :)


That would be fun if I could get in touch.
Mar 26
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Mar 28
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
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.
Mar 29
parent Mike Shah <mshah.475 gmail.com> writes:
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.
Mar 29
prev sibling parent reply Manu <turkeyman gmail.com> writes:
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.
Mar 19
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/19/2025 12:47 AM, Manu wrote:

 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.


I'm painfully aware of the template bloat.

Adam Wilson is in charge of Phobos 3. Let him know!
Mar 27
prev sibling next sibling parent reply Bradley Chatha <sealabjaster gmail.com> writes:
On Tuesday, 18 March 2025 at 20:00:01 UTC, Maximilian Naderer 
wrote:

 ...
 Max


Thoroughly enjoyed his reactions (and mild disappointments!). 
We're definitely lucky he chose to use Raylib instead of 
something more complex that might not semi-Just Work when testing 
ImportC.

Even though he wasn't really doing anything complex, it was 
pretty interesting to see how D didn't really fight him in any 
way (beyond operator overloading, and some expected BetterC 
stuff).
Mar 19
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 19 March 2025 at 08:14:37 UTC, Bradley Chatha wrote:

 On Tuesday, 18 March 2025 at 20:00:01 UTC, Maximilian Naderer 
 wrote:

 ...
 Max


 Thoroughly enjoyed his reactions (and mild disappointments!). 
 We're definitely lucky he chose to use Raylib instead of 
 something more complex that might not semi-Just Work when 
 testing ImportC.

 Even though he wasn't really doing anything complex, it was 
 pretty interesting to see how D didn't really fight him in any 
 way (beyond operator overloading, and some expected BetterC 
 stuff).


We are using it with ffmpeg, and it's amazing, as ffmpeg has a 
very aggressive approach in changing the API between different 
versions, so bindings are expensive to maintain.

It's definitely a wow feature.

/P
Mar 19
parent reply Sergey <kornburn yandex.ru> writes:
On Wednesday, 19 March 2025 at 10:18:53 UTC, Paolo Invernizzi 
wrote:

 We are using it with ffmpeg, and it's amazing, as ffmpeg has a 
 very aggressive approach in changing the API between different 
 versions, so bindings are expensive to maintain.

 It's definitely a wow feature.

 /P


Still not unique as I understand.
Many langs have tools for that..

Go and Zig have kinda similar things: cgo and cImport
While Rust prefer auto generating approach (bindgen).
Mar 19
parent Kapendev <alexandroskapretsos gmail.com> writes:
On Wednesday, 19 March 2025 at 10:39:54 UTC, Sergey wrote:

 On Wednesday, 19 March 2025 at 10:18:53 UTC, Paolo Invernizzi 
 Still not unique as I understand.
 Many langs have tools for that..

 Go and Zig have kinda similar things: cgo and cImport
 While Rust prefer auto generating approach (bindgen).


Cgo is not similar to importC.
Both Zig's cImport and D's importC are unique features that 
simplify the traditionally process of creating bindings.
Mar 19
prev sibling next sibling parent reply Ogion <ogion.art gmail.com> writes:
On Tuesday, 18 March 2025 at 20:00:01 UTC, Maximilian Naderer 
wrote:

 Not sure if you are aware a pretty big Streamer made a video 
 about D!


Is this why I just got server overloaded error while browsing 
dlang.org?
Mar 19
parent bauss <jacobbauss gmail.com> writes:
On Wednesday, 19 March 2025 at 08:43:49 UTC, Ogion wrote:

 On Tuesday, 18 March 2025 at 20:00:01 UTC, Maximilian Naderer 
 wrote:

 Not sure if you are aware a pretty big Streamer made a video 
 about D!


 Is this why I just got server overloaded error while browsing 
 dlang.org?


Probably not. It happens sometimes
Mar 19
prev sibling next sibling parent reply matheus <matheus gmail.com> writes:
On Tuesday, 18 March 2025 at 20:00:01 UTC, Maximilian Naderer 
wrote:

 ...


I wonder if downloads or site in general had any increase in 
views after that video.

By the way Mike Parker after Adam D. Ruppe interview, you should 
try this guy because it could help to bring more views to the 
community.

Remember Scott Meyers? Maybe invite him to the DConf?

Matheus.
Mar 19
next sibling parent Sergey <kornburn yandex.ru> writes:
On Thursday, 20 March 2025 at 00:44:31 UTC, matheus wrote:

 On Tuesday, 18 March 2025 at 20:00:01 UTC, Maximilian Naderer 
 wrote:

 ...


 I wonder if downloads or site in general had any increase in 
 views after that video.


I’m not sure it will have such strong effect


 By the way Mike Parker after Adam D. Ruppe interview, you 
 should try this guy because it could help to bring more views 
 to the community.


He is not a D dev :) he just used D for a stream


 Remember Scott Meyers? Maybe invite him to the DConf?



will be epic!! xD
Mar 19
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Mar 28
prev sibling next sibling parent bomat <Tempest_spam gmx.de> writes:
On a completely different note, I loved the part at the end where 
Tsoding got confused about the `enum` keyword being used for 
string manifest constants.
At least I'm not the only one. :)
https://forum.dlang.org/post/amwowypgebdkktwnsfum forum.dlang.org
Time stamp in the video:
https://www.youtube.com/watch?v=Gj5310KnUTQ&t=7396s
Mar 25
prev sibling next sibling parent reply Dave P. <dave287091 gmail.com> writes:
On Tuesday, 18 March 2025 at 20:00:01 UTC, Maximilian Naderer 
wrote:

 Hello guys,

 Not sure if you are aware a pretty big Streamer made a video 
 about D!

 Not that it’s important for me but he is really impressed with 
 the language and was blown away a couple of times.

 https://youtu.be/Gj5310KnUTQ?si=rSP50Uf9oeb4vLm1

 Best regards,
 Max


He streamed again, (vod is here: 
https://www.twitch.tv/videos/2415069952) and had a very negative 
experience trying to use betterC.

Lots of fixable issues he runs into.
Mar 26
parent reply Sergey <kornburn yandex.ru> writes:
On Thursday, 27 March 2025 at 05:41:59 UTC, Dave P. wrote:

 He streamed again, (vod is here: 
 https://www.twitch.tv/videos/2415069952) and had a very 
 negative experience trying to use betterC.

 Lots of fixable issues he runs into.


I won't say it was "very negative" but he had some frustration 
about several things..
Especially naming of "betterC" is misleading

And discord people have a proposal for renaming to "no-druntime" 
(as GDC already doing).
Mar 27
parent reply Kapendev <alexandroskapretsos gmail.com> writes:
On Thursday, 27 March 2025 at 07:43:33 UTC, Sergey wrote:

 On Thursday, 27 March 2025 at 05:41:59 UTC, Dave P. wrote:

 He streamed again, (vod is here: 
 https://www.twitch.tv/videos/2415069952) and had a very 
 negative experience trying to use betterC.

 Lots of fixable issues he runs into.


 I won't say it was "very negative" but he had some frustration 
 about several things..
 Especially naming of "betterC" is misleading

 And discord people have a proposal for renaming to 
 "no-druntime" (as GDC already doing).


The stream was okay, but it got funny at the end. My main 
takeaway is that the experience for new users trying to use D 
without GC isn't great. It seems like things would be easier if 
he knew about ` nogc` and `nothrow`, but most people start by 
learning about betterC first, which is an advanced and kind of 
weird feature.
Mar 27
parent reply Meta <jared771 gmail.com> writes:
On Thursday, 27 March 2025 at 12:08:45 UTC, Kapendev wrote:

 On Thursday, 27 March 2025 at 07:43:33 UTC, Sergey wrote:

 On Thursday, 27 March 2025 at 05:41:59 UTC, Dave P. wrote:

 He streamed again, (vod is here: 
 https://www.twitch.tv/videos/2415069952) and had a very 
 negative experience trying to use betterC.

 Lots of fixable issues he runs into.


 I won't say it was "very negative" but he had some frustration 
 about several things..
 Especially naming of "betterC" is misleading

 And discord people have a proposal for renaming to 
 "no-druntime" (as GDC already doing).


 My main takeaway is that the experience for new users trying to 
 use D without GC isn't great.


More that the experience for users who disable the language's 
runtime isn't great. He didn't seem to understand that that's 
what betterC does, hence complaining that he can't use Phobos or 
the precompiled runtime library with it.

We should undocument and/or deprecate that stupid flag, because 
it only causes confusion and frustration, as seen in the video.
Mar 27
parent reply Sergey <kornburn yandex.ru> writes:
On Thursday, 27 March 2025 at 13:04:45 UTC, Meta wrote:

 We should undocument and/or deprecate that stupid flag, because 
 it only causes confusion and frustration, as seen in the video.


In that case he won't even try to use D =)
Mar 27
parent reply Mike Shah <mshah.475 gmail.com> writes:
On Thursday, 27 March 2025 at 13:10:24 UTC, Sergey wrote:

 On Thursday, 27 March 2025 at 13:04:45 UTC, Meta wrote:

 We should undocument and/or deprecate that stupid flag, 
 because it only causes confusion and frustration, as seen in 
 the video.


 In that case he won't even try to use D =)


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.

It took me a while as to keep straight what D was, betterC, and 
importC when I got active with D. It's on my toso list to make a 
video (I haven't covered betterC yet) on YouTube to help 
straighten this out for other newcomers.

I suspect most folks still start with D and Phobos when learning, 
and then otherwise find betterC when they want to do more 
embedded/OS/bare metal things.
Mar 27
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
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.

I am very cautious and rather unhappy at the connection people are 
drawing between the two. The distinction matters and would only cause 
pain to conflate, should any alterations were to be made.
Mar 27
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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.

 I am very cautious and rather unhappy at the connection people 
 are drawing between the two. The distinction matters and would 
 only cause pain to conflate, should any alterations were to be 
 made.


The spec for betterC (https://dlang.org/spec/betterc.html) starts 
off by saying that it doesn't depend on the D runtime library, 
only the C one.

So perhaps there is a way to make it clearer about what the 
purpose/motivation is and what exactly it is doing?
Mar 27
next sibling parent Derek Fawcus <dfawcus+dlang employees.org> writes:
On Thursday, 27 March 2025 at 16:41:48 UTC, jmh530 wrote:

 The spec for betterC (https://dlang.org/spec/betterc.html) 
 starts off by saying that it doesn't depend on the D runtime 
 library, only the C one.


Maybe it should not only say that it does not depend upon the 
runtime, but also does not support large portions of the standard 
library as they depend upon the runtime?
Mar 27
prev sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 28/03/2025 5:41 AM, jmh530 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.

 I am very cautious and rather unhappy at the connection people are 
 drawing between the two. The distinction matters and would only cause 
 pain to conflate, should any alterations were to be made.


 
 The spec for betterC (https://dlang.org/spec/betterc.html) starts off by 
 saying that it doesn't depend on the D runtime library, only the C one.
 
 So perhaps there is a way to make it clearer about what the purpose/ 
 motivation is and what exactly it is doing?


I'm inclined to suggest that we need a giant red warning on that page 
basically stating that not linking against druntime has intended 
implications that will result in loss of polish for the language.
Mar 27
parent reply Derek Fawcus <dfawcus+dlang employees.org> writes:
On Thursday, 27 March 2025 at 17:06:11 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 28/03/2025 5:41 AM, jmh530 wrote:

 On Thursday, 27 March 2025 at 14:06:43 UTC, Richard (Rikki) 
 Andrew Cattermole wrote:
 The spec for betterC (https://dlang.org/spec/betterc.html) 
 starts off by saying that it doesn't depend on the D runtime 
 library, only the C one.
 
 So perhaps there is a way to make it clearer about what the 
 purpose/ motivation is and what exactly it is doing?


 I'm inclined to suggest that we need a giant red warning on 
 that page basically stating that not linking against druntime 
 has intended implications that will result in loss of polish 
 for the language.


Isn't it just his particular thing to wind folks up?

In experimenting with betterC, I went in eyes open, rather 
expecting to have little or no support from the standard library 
(other than the bits under core.stdc, even if them).

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.
Mar 27
next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 27 March 2025 at 17:16:07 UTC, Derek Fawcus wrote:

 On Thursday, 27 March 2025 at 17:06:11 UTC, Richard (Rikki) 
 Andrew Cattermole wrote:

 On 28/03/2025 5:41 AM, jmh530 wrote:

 [...]


 I'm inclined to suggest that we need a giant red warning on 
 that page basically stating that not linking against druntime 
 has intended implications that will result in loss of polish 
 for the language.


 Isn't it just his particular thing to wind folks up?

 In experimenting with betterC, I went in eyes open, rather 
 expecting to have little or no support from the standard 
 library (other than the bits under core.stdc, even if them).

 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.


What he's pointing out is that importing the provided core 
modules is not 'on par' with importing the equivalent C header 
with a C compiler. Macro translated into functions on D side are 
missing.
Mar 27
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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?
Mar 28
parent Derek Fawcus <dfawcus+dlang employees.org> writes:
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.
Mar 29
prev sibling parent reply Meta <jared771 gmail.com> writes:
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.
Mar 27
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
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.
Mar 27
prev sibling parent reply cc <us86kj+3rxcwe3ebdv7w grr.la> writes:
On Tuesday, 18 March 2025 at 20:00:01 UTC, Maximilian Naderer 
wrote:

 https://youtu.be/Gj5310KnUTQ?si=rSP50Uf9oeb4vLm1


"Garbage collected slop language... you also can precisely align 
structures."

D's new official tagline?
Mar 27
parent reply Derek Fawcus <dfawcus+dlang employees.org> writes:
On Thursday, 27 March 2025 at 08:47:52 UTC, cc wrote:

 On Tuesday, 18 March 2025 at 20:00:01 UTC, Maximilian Naderer 
 wrote:

 https://youtu.be/Gj5310KnUTQ?si=rSP50Uf9oeb4vLm1


 "Garbage collected slop language... you also can precisely 
 align structures."

 D's new official tagline?


Is he saying "slop" or "slope"? It sounds like the latter to me.

Then the question is just what does he mean by referring to the 
language in such a term?
Mar 27
parent reply Meta <jared771 gmail.com> writes:
On Thursday, 27 March 2025 at 10:50:46 UTC, Derek Fawcus wrote:

 On Thursday, 27 March 2025 at 08:47:52 UTC, cc wrote:

 On Tuesday, 18 March 2025 at 20:00:01 UTC, Maximilian Naderer 
 wrote:

 https://youtu.be/Gj5310KnUTQ?si=rSP50Uf9oeb4vLm1


 "Garbage collected slop language... you also can precisely 
 align structures."

 D's new official tagline?


 Is he saying "slop" or "slope"? It sounds like the latter to me.

 Then the question is just what does he mean by referring to the 
 language in such a term?


It's "slop". It's a newer internet slang term meaning something 
that is popular and/or widely used but is very low effort and is 
designed to be just good enough for the majority. In this case he 
uses it to refer to the GC, and languages that have a GC are 
"slop languages".
Mar 27
next sibling parent Guillaume Piolat <first.nam_e gmail.com> writes:
On Thursday, 27 March 2025 at 11:49:25 UTC, Meta wrote:

 It's "slop". It's a newer internet slang term meaning something 
 that is popular and/or widely used but is very low effort and 
 is designed to be just good enough for the majority. In this 
 case he uses it to refer to the GC, and languages that have a 
 GC are "slop languages".


D can bring those C/raylib/no-gc/no-package-manager types to 
modern times
Mar 27
prev sibling parent Send Help <there_are_snakes_in_my_walls example.com> writes:
On Thursday, 27 March 2025 at 11:49:25 UTC, Meta wrote:

 It's "slop". It's a newer internet slang term meaning something 
 that is popular and/or widely used but is very low effort and 
 is designed to be just good enough for the majority. In this 
 case he uses it to refer to the GC, and languages that have a 
 GC are "slop languages".


His using "slop" here is itself slop: applying the form but 
forgoing the substance of the term's meaningful application. But 
he's a pop streamer, so it's a given.
Mar 27