Hi, I think it would be interesting to have a compiler flag to inject imports into all compiling .d files.

This would be basically just extending the built-in implicit import object; that's in every non-betterC D file with any custom file you, or the build tool, might want to add.

Use cases:

• small application templates/modes with common imports set (like std.stdio, std.conv, std.algorithm, std.array, std.format) so you can more easily and quickly prototype (C# 10 / .NET 6 for example added this with implicit usings, though I'm not a fan because C# is just not that good at quick prototyping like D is)

• better DUB environment injection:

  • allow to pass in package version (usually built from git tag + commit hash, or when fetched the actual version) - this currently needs workarounds by invoking some preBuildCommands, which may not work on every target machine (e.g. DCD, D-Scanner, dfmt invoking rdmd, which is usually installed, but for example not on linux distros that package each tool individually)
  • allow to define manifest constants for different features (like build config name, configuration name, passed in architecture/triple, custom defined strings from dub.json)
  • possibility to publish packages that could have a flag to inject into the global namespace, for very common stuff or debugging stuff like custom asserts
  • additionally to the Have_xyz versions we could define enum string xyz_version = "1.2.3"; to allow dependencies to act differently based on package versions
    • we could additionally expose a dubHave("packageName", "minVersion") function for conditional compilation
  • expose build options, flags, requirements, toolchain info, etc.

• allows to define special UDAs as a kind of UDA stdlib that could be used for linting, auto completion hints, static analysis etc. Think of:

  • @nullable for reference types
  • standard @suppressWarning("...") for D-Scanner or other linters
  • common, interoperable @optional, @required UDAs for all serialization libraries (maybe as a library though)

Do you like this idea? Have any suggestions? Concerns?

On Tuesday, 7 December 2021 at 09:54:40 UTC, WebFreak001 wrote:

Yes please, I'll take two! With and without -betterC (I mean, there's no such thing as a "(non-)betterC D file", they're all D files).

On Tuesday, 7 December 2021 at 09:54:40 UTC, WebFreak001 wrote:

ok correction before it goes off-topic because of this: injected into all D files

On Tuesday, 7 December 2021 at 09:54:40 UTC, WebFreak001 wrote:

[...]

https://en.wikipedia.org/wiki/Monkey_patch#Pitfalls

On Tuesday, 7 December 2021 at 09:54:40 UTC, WebFreak001 wrote:

I've suggested something similar in the past for the application code, IIRC. This would make sense if you add features such as custom literals or if you application is heavy into a specific domain (like statistics or linear algebra).

It doesn't really make sense for libraries. It would also make libraries harder to read and debug.

Good idea of for applications.
Bad idea for libraries.

On Tuesday, 7 December 2021 at 09:54:40 UTC, WebFreak001 wrote:

Implicit usings are in fact a IDE feature workaround. Behind the scenes, a hidden globalusings.g.cs file is created and added silently to the existing project. The file contains several using global directives which are a new feature in C# 10. You can manually write the same cs file, add it to the project and obtain the same effect (as long as you are using C# 10).

The same approach will not work in D because in D each file is a module, therefore the only chance is that the compiler read this global imports from a configuration file and inject them into each module.

On the other hand, placing a simple import std at the beginning of your module will have the same effect.

On Tuesday, 7 December 2021 at 14:19:20 UTC, Paul Backus wrote:

I don't see how this suggestion is related to that Wikipedia link. This is also not monkey patching at all. It's suggesting that you can add (not replace) any symbols using a custom D file that would be standardized by build tool or extended further by the user.

This is basically extending much like you can already define version = X identifiers over the command line, which DUB already does, that you can define any other values and other symbols for all DUB users.

We could use this to maintain further standard environments outside the D compiler. For DUB this is especially interesting, we could greatly improve conditional compilation with more DUB fed information and add/remove DUB defined globals for that more easily, without needing to make any compiler changes.

Could you maybe explain what exactly you meant to say with that link, how exactly problems would be introduced by having the possibility to extend or add standard global symbols, that can be overriden as usual and give errors when they are not defined?