www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - injecting imports when compiling

reply WebFreak001 <d.forum webfreak.org> writes:
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 


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?
Dec 07 2021
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
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).
Dec 07 2021
prev sibling next sibling parent Stanislav Blinov <stanislav.blinov gmail.com> writes:
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).
Dec 07 2021
prev sibling next sibling parent WebFreak001 <d.forum webfreak.org> writes:
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
Dec 07 2021
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
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
Dec 07 2021
parent WebFreak001 <d.forum webfreak.org> writes:
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?
Dec 07 2021
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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.
Dec 07 2021
prev sibling next sibling parent reply Rumbu <rumbu rumbu.ro> writes:
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, 

 / .NET 6 for example added this with implicit usings, though 

 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 

You can manually write the same cs file, add it to the project 


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.
Dec 07 2021
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Dec 07 2021
parent Stanislav Blinov <stanislav.blinov gmail.com> writes:
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.
Dec 07 2021
prev sibling parent bauss <jj_1337 live.dk> writes:
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.

 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, 

 / .NET 6 for example added this with implicit usings, though 

 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?


Another thing that would be great would be something like "import 
*;" which would import all modules in the current compilation 
unit, since traits doesn't work very well on all types in a 
package and you often can't retrieve all symbols, so being able 
to import all modules will ensure all symbols are available in a 
specific module.

This is very useful when autogenerating code based on modules 
located in multiple different packages etc.

Or at least something like what you suggested that allows to 
specific a module that has all modules imported per standard 
through command-line as you've shown, of course with a flag that 
allows exclusion of certain modules/packages ex. you probably 
would want to exclude the standard library.
Dec 07 2021