Jump to page: 1 2
Thread overview
injecting imports when compiling
Dec 07
Rumbu
Dec 08
bauss
December 07

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?

December 07
On 07/12/2021 10:54 PM, WebFreak001 wrote:
> 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.

Its in every D file.

Otherwise stuff like size_t wouldn't be defined for -betterC (which it is).
December 07

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

>

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

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).

December 07

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

>

[...]

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.

[...]

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

December 07

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

>

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

[...]

>

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

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

December 07

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

>

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

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.

December 07

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

>

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)

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.

December 07
On Tue, Dec 07, 2021 at 02:35:15PM +0000, Rumbu via Digitalmars-d wrote: [...]
> On the other hand, placing a simple ```import std``` at the beginning of your module will have the same effect.

Better yet, create a file called something like common.d containing public imports of everything you want to share across files, and just import it at the top of each file:

	// common.d
	module common;
	public import std;
	public import whatever.else.you.want;
	...

	// in each file:
	import common;


Or, if you want to be able to switch out the common import dynamically, you could use this trick I recently invented: add this to the top of every file:

	import __stdin;

then run your compile command with:

	echo 'public import std; public import whatever.else;' | dmd - mysources.d ...

Then you can inject arbitrary D code into your project via the command line.


T

-- 
People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG
December 07

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

>

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

>

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

[...]

>

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

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

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?

December 07
On Tuesday, 7 December 2021 at 14:56:56 UTC, H. S. Teoh wrote:

> import it at the top of each file

The whole point is to not have to do that. To specify the import once, on command line.
« First   ‹ Prev
1 2