On 20/12/2023 4:21 PM, Siarhei Siamashka wrote:
>     We currently have a chain of compilers if you want to bootstrap
>     latest compiler from C++.
> 
> This doesn't look good.

This is why its N compilers.

Every link in that chain of compilers has to be maintained.

Its not just a matter of maintaining the frontend, but also the glue code per version of the backend you target.

Plus druntime and phobos for good measure.

Oh and GCC has rules around what compilers may be used to compile GCC for distribution. So if D isn't already on a given target... have fun with that.



On the other hand our frontend is already marked up with ``extern(C++)``, and has manually maintained C++ headers for it.

If only we could take advantage of that.

On 12/19/2023 6:33 PM, Steven Schveighoffer wrote:
> I said you were arguing against the examples, which were in the DIP. Not the specification which also was in the DIP. Examples are examples, not specification. They *use* the feature to demonstrate its utility. They aren't intended to be part of the language additions.

I used the examples to demonstrate problems with the specification. I used the examples in the DIP so I would not be accused of making up strawmen. I assumed the examples were supposed to conform to the specification.

On 12/19/2023 6:45 PM, jmh530 wrote:
> ImportC is a cool idea. It’s just got limitations right now that prevent it from being great. If rethinking it as mixin makes it smoother to use (does your idea resolve the duplicate symbol issue?), then it could make some sense.

ImportC is already great :-) People who have been using it have reported that it has saved them gobs of time. And that's what its mission is!

The desire to extend ImportC is a clear and inevitable sign of its success.


> I don’t know if it’s an either/or sort of thing, but I think you would need to introduce this with some sort of way to migrate existing importC code since importC wasn’t put behind a preview switch.

ImportC isn't behind a preview switch because it is not a language change. Nothing changed in the language semantics.

On Wednesday, 20 December 2023 at 02:31:58 UTC, Richard (Rikki) Andrew Cattermole wrote:
> That isn't going to work long term.
>
> We already have at least one more release in between that one and current versions.
>
> Using the C++ dump approach is significantly better, you go immediately to the latest version. With the old bootstrap approach you have to maintain N frontends with their glue code indefinitely. It doesn't scale.

Just a kind request, Rikki, can you partially quote the text you are replying? Reading the messages in 'basic' view mode in the forum is a little messy otherwise.

On Wednesday, 20 December 2023 at 07:47:12 UTC, Walter Bright wrote:
> On 12/19/2023 6:33 PM, Steven Schveighoffer wrote:
>> I said you were arguing against the examples, which were in the DIP. Not the specification which also was in the DIP. Examples are examples, not specification. They *use* the feature to demonstrate its utility. They aren't intended to be part of the language additions.
>
> I used the examples to demonstrate problems with the specification. I used the examples in the DIP so I would not be accused of making up strawmen. I assumed the examples were supposed to conform to the specification.

no, you took the examples while completely misunderstanding what the specification actually said, and then argued a strawman with those examples.
that's why you are now told to "just look at the implementation", because you cannot misunderstand that one.

if you insist on a specification, ask the D language foundation to pay someone to write one.

On Wednesday, 20 December 2023 at 00:20:38 UTC, GrimMaple wrote:
> I don't have this pathological hatred towards phobos that some other Devs have and my code does rely on it heavily. That being said, phobos is really lacking in features. Also, it is a mess of incompatible paradigms. To me, a good example is C#'s `System`, that gets you 99% of what you want from the get go. Phobos, unfortunately, provides about 10% at best.

This is exactly what I mean when I say that Phobos should get bigger, not smaller. Phobos needs to incorporate more features that have broad applicability (Cross-cutting concerns). For example, server-apps, desktop/mobile-apps, embedded-apps all may have use for a Streams type interface, all for different reasons, but providing a standard Stream interface would allow all of those apps to interoperate with less friction.

> I don't really care for speed in a standard library, for me it should allow me to get stuff done quickly. I can swap out for an optimized solution later if needed.

If somebody really wants to, they can put an optimized version on DUB. But in general, people generally don't know what packages to use, and so they don't. By putting the kitchen sink into Phobos we're saying "here are known good implementations of the tools you need."

On Wednesday, 20 December 2023 at 11:19:55 UTC, duckchess wrote:
> On Wednesday, 20 December 2023 at 07:47:12 UTC, Walter Bright wrote:
>> On 12/19/2023 6:33 PM, Steven Schveighoffer wrote:
>>> I said you were arguing against the examples, which were in the DIP. Not the specification which also was in the DIP. Examples are examples, not specification. They *use* the feature to demonstrate its utility. They aren't intended to be part of the language additions.
>>
>> I used the examples to demonstrate problems with the specification. I used the examples in the DIP so I would not be accused of making up strawmen. I assumed the examples were supposed to conform to the specification.
>
> no, you took the examples while completely misunderstanding what the specification actually said, and then argued a strawman with those examples.
> that's why you are now told to "just look at the implementation", because you cannot misunderstand that one.
>
> if you insist on a specification, ask the D language foundation to pay someone to write one.

It can also be funny!

I would say: just directly try-out to code some more example, and see out it behave, when you are in doubt about the specification or if you think there's some ambiguity in it.

Everything is perfectible of course!

/P