Re: `static` on module-level functions
On Friday, 7 July 2023 at 13:31:59 UTC, Steven Schveighoffer wrote: However, I can't think of a valid reason to allow `static` on a module-level scope. Applying static to a declaration at module-level should be a no-op. So maybe that's one "use" of static that can be eliminated. Well, it can be used to work around this bug: https://issues.dlang.org/show_bug.cgi?id=17435 So we might want to fix that issue before we make module-level `static` an error.
Re: Public visible entities published by a module
On Friday, 7 July 2023 at 19:49:06 UTC, Anonymouse wrote:
On Friday, 7 July 2023 at 17:46:09 UTC, Cecil Ward wrote:
[...]
I did this. It's super ugly and even has `__traits(compiles)`
in there, but as a quick and dirty solution it served well
enough.
```d
void printPublicMembersOfModule(string module_)()
{
mixin("import thisModule = " ~ module_ ~ ";");
foreach (symstring; __traits(allMembers, thisModule))
{
alias symbol = __traits(getMember, thisModule,
symstring);
static if (
__traits(compiles, __traits(getVisibility, symbol))
&&
__traits(getVisibility, symbol) == "public")
{
pragma(msg, symstring);
}
}
}
void main()
{
printPublicMembersOfModule!"std.stdio"();
}
```
https://run.dlang.io/is/tvNDdp
Wow, thankyou so much for your generous reply.
Re: Public visible entities published by a module
On Friday, 7 July 2023 at 17:46:09 UTC, Cecil Ward wrote:
A bit of a weird question, and I’m not sure how to word it. Say
I have a module, and I’d like to list / enumerate all the
public visible things that the module exports / publishes ‘
makes visible. Is there a way of doing that ? Of getting that
kind of listing?
I’m wondering about information leaking when things should be
encapsulated.
I did this. It's super ugly and even has `__traits(compiles)` in
there, but as a quick and dirty solution it served well enough.
```d
void printPublicMembersOfModule(string module_)()
{
mixin("import thisModule = " ~ module_ ~ ";");
foreach (symstring; __traits(allMembers, thisModule))
{
alias symbol = __traits(getMember, thisModule, symstring);
static if (
__traits(compiles, __traits(getVisibility, symbol)) &&
__traits(getVisibility, symbol) == "public")
{
pragma(msg, symstring);
}
}
}
void main()
{
printPublicMembersOfModule!"std.stdio"();
}
```
https://run.dlang.io/is/tvNDdp
Public visible entities published by a module
A bit of a weird question, and I’m not sure how to word it. Say I have a module, and I’d like to list / enumerate all the public visible things that the module exports / publishes ‘ makes visible. Is there a way of doing that ? Of getting that kind of listing? I’m wondering about information leaking when things should be encapsulated.
Re: First module
On Friday, 7 July 2023 at 14:18:35 UTC, Richard (Rikki) Andrew Cattermole wrote: 1. Compiler reads in source code provided on cli 2. It gets parsed 3. imports get looked up, if not already read in, looks in the directories provided by -I based upon the full module + package import statement 4. Finish compilation 5. Linker gets passed object files to produce some artifact like an executable Very rough idea of how it works, but will do for what you are asking about. As long as you compile all at once, assume inlining will work if it thinks it should. Modules will not affect it. Brilliant, thanks Rikki.
Re: First module
1. Compiler reads in source code provided on cli 2. It gets parsed 3. imports get looked up, if not already read in, looks in the directories provided by -I based upon the full module + package import statement 4. Finish compilation 5. Linker gets passed object files to produce some artifact like an executable Very rough idea of how it works, but will do for what you are asking about. As long as you compile all at once, assume inlining will work if it thinks it should. Modules will not affect it.
Re: First module
On Thursday, 6 July 2023 at 21:10:39 UTC, Cecil Ward wrote: I’ve written my first non-trivial module in D. See other thread. https://forum.dlang.org/thread/pfjpqcywxrmxwsncy...@forum.dlang.org I’d like to set up something to call it from other modules, and specifically I’d like to see if inlining works across module boundaries - I have no idea whether it does or not as I don’t understand fully in detail how module imports work. How do I go about setting up such a test harness with LDC (or GDC) on either OSX/ARM or Linux Debian x86-64? I’m not sure what tools I need. Note that I cannot use DMD, this code is LDC/GDC-specific. LDC would be my preference as that is what it is ultimately aimed at. Do I just provide two filenames as inputs to the compiler ? I’m wondering if the compiler resolves the import statements rather than the linker - is that right? I only have a vague understanding of how the import statement works - pulling in digested intermediate-code or something? Will in-line functions be inlined even if the called routine is across a module boundary?
Re: `static` on module-level functions
On 7/7/23 6:38 AM, IchorDev wrote:
Well yes, I even mentioned that in the OP. It's just that I'd expect
using `static` "incorrectly" to cause an error, like `const` does.
Instead, marking something as `static` *actually* does nothing, and
nothing really tells you, so it causes a bit of a placebo effect.
D allows no-op attributes in many cases because you can possibly apply
attributes to a group via `attribute:` or `attribute { ... }`, and you
may not want to fine-tune which things can get the attribute to avoid
errors.
Here's a fun one:
```d
enum foo() {
return "what?";
}
```
What does this mean? `enum` is a storage class, and any storage class
applied to a function is going to cause the function to be inferred
return type. So effectively, the `enum` does nothing but take the place
of `auto`. (`foo` is a function that returns `string`)
However, I can't think of a valid reason to allow `static` on a
module-level scope. Applying static to a declaration at module-level
should be a no-op. So maybe that's one "use" of static that can be
eliminated.
-Steve
Re: `static` on module-level functions
On Friday, 7 July 2023 at 10:01:41 UTC, Richard (Rikki) Andrew Cattermole wrote: Static does do something on functions when they are not free-functions. https://dlang.org/spec/attribute.html#static Well yes, I even mentioned that in the OP. It's just that I'd expect using `static` "incorrectly" to cause an error, like `const` does. Instead, marking something as `static` *actually* does nothing, and nothing really tells you, so it causes a bit of a placebo effect. https://issues.dlang.org/show_bug.cgi?id=24038 Thank you! :)
Re: Easiest CI to build on github.com
On Friday, 7 July 2023 at 10:29:14 UTC, Richard (Rikki) Andrew Cattermole wrote: I believe: https://github.com/dlang-community/setup-dlang Thx! — Dmitry Olshansky CEO @ Glow Labs https://olshansky.me https://t.me/glowlabs32
Re: Easiest CI to build on github.com
I believe: https://github.com/dlang-community/setup-dlang
Easiest CI to build on github.com
Simply enough dub test should pass. How do I go about it? — Dmitry Olshansky CEO @ Glow Labs https://olshansky.me https://t.me/glowlabs32
Re: `static` on module-level functions
Static does do something on functions when they are not free-functions. https://dlang.org/spec/attribute.html#static However yes, it does not describe what a free-function is there. https://issues.dlang.org/show_bug.cgi?id=24038
Re: `static` on module-level functions
On Friday, 7 July 2023 at 03:18:53 UTC, Richard (Rikki) Andrew Cattermole wrote: Yes, static on a free-function does not do anything. Good to know. I think the D spec should definitely be amended to explicitly mention that static *can* be applied to them, but doesn't do anything.
Re: Compiler interoperability
On Friday, 7 July 2023 at 08:19:28 UTC, Chris Katko wrote: For a specific system (Linux, e.g): What is the level of interoperability between the different D compilers; DMD, LDC, and GDC? It appears each one has different benefits, and, different experimental features. Link-time optimization for LDC. GDC offering static analysis. I imagine there are more. If I compile a D program with say, DMD, will every D library I include also have to use that same compiler Yes because of exception handling, the runtime functions are different. You can try and you'll see linking error because of a missing "*personality*", symbol. (and compiler version) from scratch and need recompiled? From version to version of a same vendor that might work but as phobos is not binary compatible (ABI of functions is allowed to change from a version to another) this is a bit the lottery. Or is there a pre-defined ABI that makes everything compatible? If I use shared libraries instead of static linking, does the situation change? Additionally, how do the debuggers GDB vs LLDB behave when compiled using a different brand D compiler? (e.g. demangling) Mangling is identical for each vendor (this is a language spec) but as mentioned, EH functions are different so the breakpoint set to break on `throw` for DMD (i.e `_d_throwdwarf`) will not work for `LDC` (i.e `_d_throw_exception`) I have my own experiences but I'm not sure if there's clear cut "yes, definitely it's [this case]." answers out there. So to conclude there's no interoperability
