On 5/18/2022 8:34 AM, Max Samukha wrote:
> Moreover, after DIP1030 is implemented, D wants to deprecate anonymous struct literals entirely, which makes me the unhappiest man in the world.

DIP1030 is not moving forward.

On Wed, May 18, 2022 at 11:57:13AM -0700, Walter Bright via Digitalmars-d wrote: [...]
> For example, look at the dmd source code itself. We maintain, by hand, a set of equivalent .h for them. A cumulatively enormous amount of time has been expended on that, and finding/fixing the bugs from when they get out of sync.
[.[..]

This is, to me, a flashing red (and beeping) neon sign begging for auto-generation of .h from .d.  At least, that's what I'd do in my own project if I faced a similar situation.

It's never a good idea to maintain two (slightly different) copies of
the same thing by hand.


T

-- 
Why do conspiracy theories always come from the same people??

On Wednesday, 18 May 2022 at 19:07:38 UTC, H. S. Teoh wrote:
> On Wed, May 18, 2022 at 11:57:13AM -0700, Walter Bright via Digitalmars-d wrote: [...]
>> For example, look at the dmd source code itself. We maintain, by hand, a set of equivalent .h for them. A cumulatively enormous amount of time has been expended on that, and finding/fixing the bugs from when they get out of sync.
> [.[..]
>
> This is, to me, a flashing red (and beeping) neon sign begging for auto-generation of .h from .d.  At least, that's what I'd do in my own project if I faced a similar situation.
>
> It's never a good idea to maintain two (slightly different) copies of
> the same thing by hand.
>
>
> T

In this case it's actually a really good idea because politically it forces people to try and look after the C++ header interface.

One day it'll likely be more automated but until that automation can detect nasty changes it's better to have the frontend.h diff be extremely obvious.

On Wednesday, 18 May 2022 at 18:58:51 UTC, Walter Bright wrote:
> DIP1030 is not moving forward.

Is this the official announcement :thonk:

On Wednesday, 18 May 2022 at 18:58:51 UTC, Walter Bright wrote:
> On 5/18/2022 8:34 AM, Max Samukha wrote:
>> Moreover, after DIP1030 is implemented, D wants to deprecate anonymous struct literals entirely, which makes me the unhappiest man in the world.
>
> DIP1030 is not moving forward.

Named arguments (the important part of DIP1030) will happen.

This week in particular I'm going to refactor the compilers notion of function arguments into a struct that can represent both the semantically lowered by also original lexical order of arguments.

Previously I tried doing this as additional data but it just became extremely hard to work with. I got named arguments working for non-templated functions but I could never get the logic covering all cases for all the difference flavours of template matching in the compiler.

Unifying all this to one notion of arguments should massively simplify resulting logic.

On Wed, May 18, 2022 at 07:08:59PM +0000, max haughton via Digitalmars-d wrote:
> On Wednesday, 18 May 2022 at 19:07:38 UTC, H. S. Teoh wrote:
> > On Wed, May 18, 2022 at 11:57:13AM -0700, Walter Bright via Digitalmars-d wrote: [...]
> > > For example, look at the dmd source code itself. We maintain, by hand, a set of equivalent .h for them. A cumulatively enormous amount of time has been expended on that, and finding/fixing the bugs from when they get out of sync.
> > [...]
> > 
> > This is, to me, a flashing red (and beeping) neon sign begging for auto-generation of .h from .d.  At least, that's what I'd do in my own project if I faced a similar situation.
> > 
> > It's never a good idea to maintain two (slightly different) copies
> > of the same thing by hand.
[...]
> In this case it's actually a really good idea because politically it forces people to try and look after the C++ header interface.
> 
> One day it'll likely be more automated but until that automation can detect nasty changes it's better to have the frontend.h diff be extremely obvious.

What nasty changes are there?


T

-- 
Your inconsistency is the only consistent thing about you! -- KD

On Wednesday, 18 May 2022 at 19:20:58 UTC, H. S. Teoh wrote:
> On Wed, May 18, 2022 at 07:08:59PM +0000, max haughton via Digitalmars-d wrote:
>> On Wednesday, 18 May 2022 at 19:07:38 UTC, H. S. Teoh wrote:
>> > [...]
> [...]
>> In this case it's actually a really good idea because politically it forces people to try and look after the C++ header interface.
>> 
>> One day it'll likely be more automated but until that automation can detect nasty changes it's better to have the frontend.h diff be extremely obvious.
>
> What nasty changes are there?
>
>
> T

You'll have to ask Iain and Martin since they are on the front lines but it is very easy to break the C++ interface to the compiler if you so wish.

On Wed, May 18, 2022 at 07:26:28PM +0000, max haughton via Digitalmars-d wrote:
> On Wednesday, 18 May 2022 at 19:20:58 UTC, H. S. Teoh wrote:
> > On Wed, May 18, 2022 at 07:08:59PM +0000, max haughton via Digitalmars-d wrote:
> > > On Wednesday, 18 May 2022 at 19:07:38 UTC, H. S. Teoh wrote:
> > > > [...]
> > [...]
> > > In this case it's actually a really good idea because politically it forces people to try and look after the C++ header interface.
> > > 
> > > One day it'll likely be more automated but until that automation can detect nasty changes it's better to have the frontend.h diff be extremely obvious.
> > 
> > What nasty changes are there?
[...]
> You'll have to ask Iain and Martin since they are on the front lines but it is very easy to break the C++ interface to the compiler if you so wish.

Ah I got it, we have to preserve the C++ interface in order to integrate with the LLVM/GCC backends, right?

In that case, if I were put in the same situation, I'd auto-generate a .di from the C++ .h instead.  Basically, I'm wary of maintaining two parallel versions of the same thing, because the chances of human error causing them to go out of sync is just too high.  Let the machine do what it's best at; leave the human to do what humans are good at, which is NOT repetitive tasks that require high accuracy.


T

-- 
A bend in the road is not the end of the road unless you fail to make the turn. -- Brian White

On Wednesday, 18 May 2022 at 19:36:32 UTC, H. S. Teoh wrote:
> On Wed, May 18, 2022 at 07:26:28PM +0000, max haughton via Digitalmars-d wrote:
>> On Wednesday, 18 May 2022 at 19:20:58 UTC, H. S. Teoh wrote:
>> > On Wed, May 18, 2022 at 07:08:59PM +0000, max haughton via Digitalmars-d wrote:
>> > > > [...]
>> > [...]
>> > > [...]
>> > 
>> > What nasty changes are there?
> [...]
>> You'll have to ask Iain and Martin since they are on the front lines but it is very easy to break the C++ interface to the compiler if you so wish.
>
> Ah I got it, we have to preserve the C++ interface in order to integrate with the LLVM/GCC backends, right?
>
> In that case, if I were put in the same situation, I'd auto-generate a .di from the C++ .h instead.  Basically, I'm wary of maintaining two parallel versions of the same thing, because the chances of human error causing them to go out of sync is just too high.  Let the machine do what it's best at; leave the human to do what humans are good at, which is NOT repetitive tasks that require high accuracy.
>
>
> T
I think you have it backwards.

GCC and LDC both use the D frontend sources, but their glue code is written in C++. This means that they need C++ binding s *to* the frontend. A .di file would be pointless because there would be no one to consume it.