On 20/12/2023 9:32 AM, Walter Bright wrote:
> On 12/5/2023 1:26 PM, GrimMaple wrote:
>> If you design a `@nogc` library, then GC people are left out.
> 
> GC code can call @nogc code, so I'm not sure how they are left out.

One reason would be callbacks.

I.e.

```d
void func(scope void function() @nogc del) @nogc {
	del();
}

void callback() {

}

func(&callback);
```

The easiest solution to make that work that I've come up with is to invalidate both ``@nogc`` attributes when the argument to func hasn't got it.

On 12/19/2023 6:17 AM, Luna wrote:
> All the software my company (Kitsunebi Games) and my main project, Inochi2D, is written in D.
> 
> I am currently also speccing out a new UI toolkit for use in the Inochi2D project with a more modern look, working on a [library](https://github.com/Inochi2D/numem) to make DLang usable without a GC while still maintaining support for classes and such to make D libraries more usable outside of D, and such.
> 
> Inochi2D is also by extension bringing new blood in to the D community through people interested in contributing to the project, as well as people getting interested in D by extension of Inochi2D being written in D. And as it stands unless Walter does something really stupid with the language I do not intend switching away from D.
> 
> That being said I do sometimes feel like I need to maintain my own corner of the D ecosystem due to the lack of well maintained libraries, but hopefully the new blood joining through the Inochi2D community will help maintain all the libraries and apps I'm creating, heh.
> 
> Additionally, I now collaborate with the Dplug maintainers to make libraries more usable across the language ecosystem besides just Inochi2D.
> 
> One thing to hope is that the NLnet grant I applied for goes through, would mean I could work another year on Inochi2D and surrounding libraries instead of taking on contract work, thereby expanding the part of the D ecosystem made for desktop apps.

Wow! Some great work here!

On Tuesday, 19 December 2023 at 20:25:04 UTC, Walter Bright wrote:
> On 12/19/2023 11:32 AM, Konstantin wrote:
>> Is there a public list of problems/improvements in phobos/dmd that a beginner can deal with?
>
> https://issues.dlang.org/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bugidtype=include&cmdtype=doit&order=Bug%20Number&remtype=asdefault&list_id=246527

Thanks!

On Tuesday, 19 December 2023 at 20:37:02 UTC, Walter Bright wrote:
> On 12/19/2023 12:07 PM, FeepingCreature wrote:
>> figure out a way to dogfood Phobos, it's insane that the premier project in the language refuses to use its stdlib)
>
> There is a good reason for that. It's very difficult to debug the compiler when the reason it is failing is a code gen bug that is breaking Phobos in some unknown way. Debugging Phobos is (unfortunately) difficult because too much of Phobos imports every other module in Phobos. (We'd like to fix that for the next iteration of Phobos.)
>
> It's hard to port dmd to a new platform when it relies on Phobos and Phobos is not working on the new platform, a chicken-and-egg problem.
>
> In order for our ease of debugging, we keep dmd's dependence on other code at a minimum.

This makes little sense to me. You wouldn't *start* by making DMD run on the new platform, but the port would start with a cross-build from your old platform to the new platform, surely? I'd want to have the testsuite and every other tool passing on the new platform before I even try running DMD natively. And this problem only arises when you try to run DMD natively from the start, right? Or am I misunderstanding?

On Tue, Dec 19, 2023 at 08:07:23PM +0000, FeepingCreature via Digitalmars-d wrote: [...]
> (seriously, figure out a way to dogfood Phobos, it's insane that the premier project in the language refuses to use its stdlib),
[...]

AIUI, this has much more to do with historical baggage than reluctance to dogfood Phobos. DMD was originally written in C++, and accordingly written in a way that's idiomatic to C++. Moreover, D has changed quite a bit over time; modern D today is quite different from the "alternative C++" that it resembled in its earlier days. A lot of modern idioms didn't even exist back then.  When the desire to bootstrap D came around, the DMD codebase was already firmly entrenched in C++ style. Thanks to the monumental efforts of a few dedicated DMD devs, an automatic translation scheme was worked out that translated, or to be more precise *transliterated* the DMD C++ code into D.  If you've done any kind of similar work before, you'd realize that this kind of process can at most give you syntactically-correct D code written in C++ style, a far cry from idiomatic D.  Which is what we have today: DMD is mostly still written in a C++-like style, with bits and pieces here and there gradually replaced by more idiomatic D.  But progress is slow -- DMD is a large, complex codebase, and you can't just rewrite it overnight.

Moreover, DMD has a long history of being fine-tuned for maximum performance. This kind of optimization cannot simply be translated overnight into idiomatic D without performance consequences. It does not mean that idiomatic D is not performant; what it means is that if you're going to rewrite a piece of C++-style optimized code in idiomatic D, you're gonna have to repeat those decades of fine-tuning and tweaking on the new Phobos-style code before you'll get on par with current performance.  It isn't as if there's a magic switch you flip to change all C++-style array/list code into Phobos ranges and you'll magically get on-par performance right out of the box. It takes time and effort to go through the code and reengineer it in the new idiom. There are different tradeoffs that you need to make decisions on, due to the different idioms employed.  And obviously, being one of the big selling points of D, fast compilation isn't something we can compromise on, even temporarily, so any such effort can't be done piecemeal, you either have to do it completely, or not do it at all.  But there's little incentive to pour in the time and effort to achieve the same performance just so we can pat ourselves on the back that yes, we did it with Phobos-using code, when the current codebase already has the performance we want. There are far too many higher-priority things to take care of than this kind of self-congratulary time and energy sink.

(Caveat: I don't speak for the dmd devs, I'm just a bystander who's fed up of people assuming and asserting things that aren't necessarily true, even from my casual POV. So take this with an appropriately-sized grain of salt.)


T

-- 
They say that "guns don't kill people, people kill people." Well I think the gun helps. If you just stood there and yelled BANG, I don't think you'd kill too many people. -- Eddie Izzard, Dressed to Kill

On Tuesday, 19 December 2023 at 19:20:30 UTC, Walter Bright wrote:
> On 12/19/2023 7:14 AM, jmh530 wrote:
>[snip]
>> I'm also confused why we can't come to some kind of agreement on issue 23479 [1]. That played out back in February and has been crickets since then.
>> 
>> [1] https://issues.dlang.org/show_bug.cgi?id=23479
>
> This is because there are people who have .h files mixed in with their .d files along the import search path, and the resulting confusion about which file gets imported.

I understand that. My point was just that still hasn't been resolved.

Steve suggested a separate import path flag for C imports. He explained [1]:

> For instance, if you want both C and D files imported from directory a/b/c, you would do -Ia/b/c -CIa/b/c. If you only wanted D files, you do -Ia/b/c. If you only wanted C files you do -CIa/b/c. If you wanted C files first, and then D files, you do -CIa/b/c -Ia/b/c.

You said it was a good idea and that it could work, but then you gave another approach of putting files with duplicate names on the command line to override search pattern behavior. Iain said that can lead to duplicate symbols. And the discussion petered out.


[1] https://github.com/dlang/dmd/pull/14864#issuecomment-1432080786

On Tuesday, 19 December 2023 at 21:42:40 UTC, jmh530 wrote:
> I understand that. My point was just that still hasn't been resolved.
>
> Steve suggested a separate import path flag for C imports. He explained

I still say the best thing to do is to ditch the overloading of the `import` keyword and instead embrace the `mixin` keyword.

mixin[C](`#include<stdio.h>`);

you can now use the full file name, with .h or .c or whatever you want. And you can do this in context of D, meaning you can do things like :

@nogc {
   mixin[C](`#include<stdio.h>`);
}


And potentially use macros:

enum C_Context = mixin[C](`#define foo bar`);
mixin[C, C_Context](`use foo here`);

or something like that.