On Tuesday, 19 December 2023 at 19:20:30 UTC, Walter Bright wrote:
> On 12/19/2023 7:14 AM, jmh530 wrote:
>> [...]
>
> I reviewed the DIP, and was informed the DIP had little to do with the implementation. I have asked for a specification of the actual implementation, and was told to read the the code.
>
> My experience with specifications is that implementing them results in discovering all kinds of oversights and errors in the specification. Implementing it first and then writing a specification reveals all kinds of shortcomings in the implementation.
>
> I'll review the proposal again when there's a specification for it. In the meantime, there is a competing proposal with specification and implementation to compare:
>
> https://github.com/dlang/dmd/pull/15722
>
>
>> [...]
>
> I'll reserve judgement on that until there is a specification.
>
>
>> [...]
>
> 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.

and DIP1027 is bad. it's been discussed to death why it's so bad. and yet you refuse to let it go and look at the proposal everyone else agrees is the best option.
it's literally why I refuse to even start to submit a DIP. it's a pointless waste of time.

On Tuesday, 19 December 2023 at 19:23:57 UTC, Walter Bright wrote:
> On 12/19/2023 6:57 AM, Hors wrote:
>> "contribute to the ecosystem" is really unclear. What we can actually contribute, new libraries? Changes to language? If it's changes to language, then what we can add (or rework) to the language?
>
> Anywhere you want to.
>
> People often ask me what they can do to help. I give them 10 options. They inevitably choose option 11, the one that they really want to do.
>
> It's all about what itch you want to scratch.

Is there a public list of problems/improvements in phobos/dmd that a beginner can deal with?

On 12/19/2023 11:29 AM, duckchess wrote:
> and DIP1027 is bad. it's been discussed to death why it's so bad. and yet you refuse to let it go and look at the proposal everyone else agrees is the best option.
> it's literally why I refuse to even start to submit a DIP. it's a pointless waste of time.

I spent a whole afternoon carefully reviewing the DIP, only to be told that wasn't what was implemented and I should read the code. That was a waste of time.

When there's a specification of it, I will give it a fair review.

On 12/19/2023 8:59 AM, IGotD- wrote:
> My opinion has now for several years been that D must be forked because there are a lot of people that wants D to progress and catch up. Walter is a no sayer that puts Linus Torvalds to shame which makes D just sitting without any progress.

On the other hand, there was a looooong recent thread about how D should stop introducing new features and work on existing ones.

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

On 12/7/2023 11:01 AM, GrimMaple wrote:
> Delegates is just one of the things where `@nogc` issues are apparent. If you want to have a `@nogc` control in a UI framework and have callbacks/events in it, you are going to force the user of that control to use `@nogc` code.

A delegate will use the GC if both these conditions apply:

1. it references variables in the function it is enclosed by

2. the delegate escapes the context of that function, i.e. it outlives the lifetime of that function, so its stack frame no longer exists. In that case, the compiler will allocate that function's stack frame using the GC.

To avoid this, do one of:

1. capture the values from the enclosed variables, rather than simply referring to them

2. don't use the delegate in such a way that it outlives the function it is nested inside

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.

You can also design code so that it simply doesn't use the GC.

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.