www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Asking for advice - assert for ImportC

reply Walter Bright <newshound2 digitalmars.com> writes:
I put in a PR to add __assert(assign-expression) to ImportC, for reasons 
explained in the PR:

https://github.com/dlang/dmd/pull/14026

Unfortunately, some C compilers use __assert. Arghh!

I seem unable to come up with a decent name. Advice welcome!
Apr 27 2022
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
Do we really need to be introducing our own unique extensions for C that 
can introduce new conflicts later on?
Apr 27 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/27/2022 9:36 PM, rikki cattermole wrote:

 Do we really need to be introducing our own unique extensions for C that can 
 introduce new conflicts later on?


No, we don't have to do this. But it makes the ImportC test suite a lot more 
convenient.
Apr 28 2022
parent reply Dennis <dkorpel gmail.com> writes:
On Thursday, 28 April 2022 at 08:05:22 UTC, Walter Bright wrote:

 No, we don't have to do this. But it makes the ImportC test 
 suite a lot more convenient.


If it's about test suite convenience, you don't need a new 
language feature. You can define your own assert template and 
import it in tests that need it. If manually importing it is too 
inconvenient as well, you can modify the test suite runner to add 
the import statement, or add it to 
[__builtins.di](https://github.com/dlang/druntime/blob/maste
/src/__builtins.di) under a version condition that's set in the test suite.
Apr 28 2022
parent reply Salih Dincer <salihdb hotmail.com> writes:
On Thursday, 28 April 2022 at 08:29:41 UTC, Dennis wrote:

 On Thursday, 28 April 2022 at 08:05:22 UTC, Walter Bright wrote:

 No, we don't have to do this. But it makes the ImportC test 
 suite a lot more convenient.


 [...] you can modify the test suite runner to add the import 
 statement, or add it to 
 [__builtins.di](https://github.com/dlang/druntime/blob/maste
/src/__builtins.di) under a version condition that's set in the test suite.


Although I don't understand it technically (what are DI files?), 
I support Dennis's opinion but I care about ImportC...

And please do whatever is necessary to make it easier.

SDB 79
Apr 28 2022
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 29/04/2022 2:24 PM, Salih Dincer wrote:

 Although I don't understand it technically (what are DI files?),


.di files are like regular .d files except by convention non-templated 
functions have their bodies removed.
Apr 28 2022
next sibling parent reply Loara <loara noreply.com> writes:
On Friday, 29 April 2022 at 02:29:25 UTC, rikki cattermole wrote:

 On 29/04/2022 2:24 PM, Salih Dincer wrote:

 Although I don't understand it technically (what are DI 
 files?),


 .di files are like regular .d files except by convention 
 non-templated functions have their bodies removed.


How I can prevent a function body from being removed in an 
interface file (because that function should be evaluated at 
compile time)?
Apr 29 2022
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 4/29/22 02:59, Loara wrote:


 How I can prevent a function body from being removed in an interface
 file


Other than templates, the compiler needs the bodies of 'auto' functions 
to determine what type they return:

auto foo() {
   // ...
}


 (because that function should be evaluated at compile time)?


You simply use the .d file that includes the definitions during compilation.

I always saw .di files as the .h equivalents of C, which are not needed 
in D but for distributing a library. (I don't think I will ever need them.)

Ali
Apr 29 2022
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Friday, 29 April 2022 at 02:29:25 UTC, rikki cattermole wrote:

 On 29/04/2022 2:24 PM, Salih Dincer wrote:

 Although I don't understand it technically (what are DI 
 files?),


 .di files are like regular .d files except by convention 
 non-templated functions have their bodies removed.


When are they needed?
Apr 29 2022
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Friday, 29 April 2022 at 13:15:10 UTC, Guillaume Piolat wrote:


 .di files are like regular .d files except by convention 
 non-templated functions have their bodies removed.


 When are they needed?


I think the primary use case would be if you want to distribute a 
closed-source library.
Apr 29 2022
prev sibling next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Friday, 29 April 2022 at 13:15:10 UTC, Guillaume Piolat wrote:

 When are they needed?


They are never needed, per se, but they have some potential in 
improving compile time by caching some results and hiding 
implementations. Especially combined with local imports, hiding 
the body can hide the entire import web, which can hide whole 
ctfe calculations.

I also think we can set it to avoid template generations by doing 
them extern if it is already in the lib which can further help 
compile times if all goes well.

The hard part is keeping it in sync. The compiler won't help you 
at all, aside from its -H generation, which isn't great. And if 
you forget to regenerate, you have possible ABI mismatch; the 
compiler won't check against an intended thing.

(This is something I'd love to see a dub 2.0 tackle.)
Apr 29 2022
parent reply Dennis <dkorpel gmail.com> writes:
On Friday, 29 April 2022 at 14:34:16 UTC, Adam D Ruppe wrote:

 The compiler won't help you at all, aside from its -H 
 generation, which isn't great.


Why not?
Apr 29 2022
parent Adam D Ruppe <destructionator gmail.com> writes:
On Friday, 29 April 2022 at 15:10:28 UTC, Dennis wrote:

 Why not?


Long list:

* it is liable to outright break code, keeping a CTFE initializer 
while stripping the body. See:

ushort listeningPort = defaultListeningPort();
cgi.di(1165): Error: `defaultListeningPort` cannot be interpreted 
at compile time, because it has no available source code

Ideally, it would actually just evaluate it and spit out the 
answer instead of keeping the function there to be rerun each 
build.

* it keeps unnecessary imports

this would need to find unneeded imports and strip them, so new 
feature, but useful one

* it keeps bodies of constructors unnecessarily

this feels like it might just be a bug, since it removes other 
function bodies, but it might also have to do with a workaround 
for the uninitialized control flow logic

* it keeps private data and members

this means more imports must be kept which is a major compile 
time cost and limits encapsulation. keeping sizes and vtables 
syncing can be tricky, but replacing private data with private 
ubyte[N] blocks might work in some cases. postblits and such 
might complicate the issue. TLS might also complicate.

* it doesn't expand mixins

if something is mixed in locally with local arguments, might as 
well expand it here and prevent work. Another case of recognizing 
when CTFE can actually be cached or not; it depends on its 
parameters.

* you can't tell it to strip static ifs and versions

sometimes those checks are themselves a bit costly and again, 
some CTFE stripping opportunities.

* it doesn't collapse unnecessary templates to reuse impls

this is easier said than done so might need to be an external 
step though, but you can avoid creating new instances if it is 
already in the object file




I think that's my big items. My view of the .di generation is it 
can be a direct companion to a .obj file - it describes what is 
needed to use the object file and caches other source things. So 
together they'd minimize work done.

This isn't always what you want from it though, maybe you want 
reuse the same .di file from different builds but really if it is 
bundled with a .obj anyway - which is the case in a cached build 
and in a closed source distribution - I think there's a lot of 
potential in speeding things up.
Apr 29 2022
prev sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 30/04/2022 1:15 AM, Guillaume Piolat wrote:

 On Friday, 29 April 2022 at 02:29:25 UTC, rikki cattermole wrote:

 On 29/04/2022 2:24 PM, Salih Dincer wrote:

 Although I don't understand it technically (what are DI files?),


 .di files are like regular .d files except by convention non-templated 
 functions have their bodies removed.


 
 When are they needed?


I will be using them for my shared libraries.

There are some expensive bits that I really don't want to be reparsed 
(nor does it need to be).

Most people probably won't need to use them as others have said.
Apr 29 2022
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Friday, 29 April 2022 at 02:24:12 UTC, Salih Dincer wrote:

 Although I don't understand it technically (what are DI files?),


https://dlang.org/dmd-linux.html#interface_files
Apr 28 2022
prev sibling next sibling parent reply Daniel N <no public.email> writes:
On Thursday, 28 April 2022 at 04:33:18 UTC, Walter Bright wrote:

 I put in a PR to add __assert(assign-expression) to ImportC, 
 for reasons explained in the PR:

 https://github.com/dlang/dmd/pull/14026

 Unfortunately, some C compilers use __assert. Arghh!

 I seem unable to come up with a decent name. Advice welcome!


_D_assert
___assert
Apr 27 2022
parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Thursday, 28 April 2022 at 06:59:24 UTC, Daniel N wrote:

 On Thursday, 28 April 2022 at 04:33:18 UTC, Walter Bright wrote:

 I put in a PR to add __assert(assign-expression) to ImportC, 
 for reasons explained in the PR:

 https://github.com/dlang/dmd/pull/14026

 Unfortunately, some C compilers use __assert. Arghh!

 I seem unable to come up with a decent name. Advice welcome!


 _D_assert
 ___assert


asserting, asserted, checking, checked, determine, guaranteed, 
debugcheck, plankcheck, deathcheck, halt_if_fails, affirmation, 
affirm, polaris (north star), harden, oneway, yieldif, 
assertcorrect, notfalse, notnottrue, proof, proving, proved...
Jul 16 2022
prev sibling next sibling parent reply Salih Dincer <salihdb hotmail.com> writes:
On Thursday, 28 April 2022 at 04:33:18 UTC, Walter Bright wrote:

 [...]
 Unfortunately, some C compilers use __assert. Arghh!


**1.**

 `__assert__`


**2.**

 `__assertion`


**3.**

 `__assertor`


**4.**

 `__asserted`


SDB 79
Apr 28 2022
parent Salih Dincer <salihdb hotmail.com> writes:
On Thursday, 28 April 2022 at 07:20:34 UTC, Salih Dincer wrote:

 On Thursday, 28 April 2022 at 04:33:18 UTC, Walter Bright wrote:

 [...]
 Unfortunately, some C compilers use __assert. Arghh!


 **1.**

 `__assert__`


 **2.**

 `__assertion`


 **3.**

 `__assertor`


 **4.**

 `__asserted`




I want to make a new suggestion to you; if the English meaning is 
not contradictory!

"ascertain" that can't introduce new conflicts never?

```d
   assert(true);
   ascertain(true);
```

Sounds good, huh? Okay, it's 3 letters more but it is better than 
underscore typed by double key press.:)

SDB 79
Jul 09 2022
prev sibling next sibling parent reply duser <duser neet.fi> writes:
On Thursday, 28 April 2022 at 04:33:18 UTC, Walter Bright wrote:

 I put in a PR to add __assert(assign-expression) to ImportC, 
 for reasons explained in the PR:

 https://github.com/dlang/dmd/pull/14026

 Unfortunately, some C compilers use __assert. Arghh!

 I seem unable to come up with a decent name. Advice welcome!


maybe `_Assert`? similar to `_Static_assert`

it almost looks like something you could expect to see in a 
future C standard

adding a prefix to the double-underscore name would be the safe 
but boring option, something like `__d_assert` or 
`__importc_assert`
Apr 28 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/28/2022 1:02 AM, duser wrote:

 maybe `_Assert`? similar to `_Static_assert`
 
 it almost looks like something you could expect to see in a future C standard
 
 adding a prefix to the double-underscore name would be the safe but boring 
 option, something like `__d_assert` or `__importc_assert`


I like __importc_assert, except it's a bit long.

I've also thought of __check() which is congruent with the compiler switch 
-checkxxxxx
Apr 29 2022
prev sibling next sibling parent zjh <fqbqrr 163.com> writes:
On Thursday, 28 April 2022 at 04:33:18 UTC, Walter Bright wrote:

 I put in a PR to add __assert(assign-expression) to ImportC,



 Unfortunately, some C compilers use __assert. Arghh!


__cassert().
Apr 29 2022
prev sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 4/27/22 21:33, Walter Bright wrote:

 I put in a PR to add __assert(assign-expression) to ImportC, for reasons 
 explained in the PR:
 
 https://github.com/dlang/dmd/pull/14026
 
 Unfortunately, some C compilers use __assert. Arghh!
 
 I seem unable to come up with a decent name. Advice welcome!


Thesaurus is my friend: "affirm" looks better than
"asseverate". :)

Ali
Apr 29 2022