On Wed, May 18, 2022 at 07:57:31PM +0000, max haughton via Digitalmars-d wrote:
> On Wednesday, 18 May 2022 at 19:36:32 UTC, H. S. Teoh wrote:
[...]
> > 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.
[...]
> 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.

The .di is to force the compiler to abort with an error if the corresponding D code doesn't match the C++ declarations. Well OK, I don't know if .di would work, perhaps the .d declarations themselves should be auto-generated. Or something like that.

Whichever direction you go, the idea is to observe SST.


T

-- 
Famous last words: I *think* this will work...

On 5/18/2022 12:32 AM, Walter Bright wrote:
> On 5/17/2022 2:11 PM, Paulo Pinto wrote:
>> Easy, they did a whole talk on the matter,
>>
>> https://www.adacore.com/nvidia
> 
> Sweet! Thanks

I watched the video, thanks. The technical issues mentioned:

1. no buffer overflows
2. no undefined behavior
3. no integer overflow
4. no integer divide by zero
5. pre and post conditions
6. prover
7. zero overhead interfacing with C
8. easy mix&match Ada and C code
9. ranged integers
10. C-like syntax

The prover seems to rely on proving the pre- and post- conditions are met by the function. Some years ago I tried this out on Spark, and found it was very limited (it was unable to deal with things like AND and OR in expressions). But perhaps that has improved over time.

D (in @safe code) has:

1, 5, 7, 8, 9

I know that @safe code eliminates a lot of undefined behavior, and we should check into eliminating all of it.

SPARC is unable to fulfill its goal without adding runtime checks, as the presentation talked about the need to use switches that eliminated those checks.

On 5/18/2022 12:46 PM, user1234 wrote:
> I dont know if it's still the case but in the past CI did not fail when a PR did  update the headers so it was not rare to see a PR following, a few days later, to fixup that.

This historically has put a really unfair burden on Iain and Martin.

On 5/18/2022 12:14 PM, max haughton wrote:
> 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.

Yes. I was referring to the removal of the { } initializer syntax. That's not going to happen, due to pushback from the community.

I did a quick look at D's undefined behavior, and nearly all of it is disallowed in @safe code.

It's not 100%, but we're in a strong position.