www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.essentials

reply Ogi <ogion.art gmail.com> writes:
DMD 2.086.0 introduced `import std`. This is very convenient for 
scripts and small apps. The downsides are compile time, the 
resulting file size, and pollution of global namespace.

When writing scripts, the file size is no concern, you just want 
to get things done as fast as possible. Globally import symbols 
can give you some fun debugging session (Oh, you forgot to define 
`name`? It’s time for you to learn about `std.compiler : name`, 
baby!). But the real dealbreaker is compile time. These extra 
hundreds of milliseconds starts to matter when you’re prototyping 
your script and recompile it every few seconds. With `import.std` 
you lose more time than you save by not importing things manually.

But if you think about it, there’s only a small portion of Phobos 
that you want to have in the most cases. So I have an idea of 
some `std.essentials` module that would publicly import the most 
commonly used Phobos modules like `std.traits`, `std.range`, 
`std.algorithm`, `std.conv` etc.

To try it out, I created a file that looks like this:

```
module essentials;

public {
	import std.traits;
	import std.range;
	import std.algorithm;
	import std.array;
	import std.string;
	import std.typecons;
	import std.stdio;
	import std.conv;
	import std.format;
	import std.exception;
}
```
I’ve tried it with a hello world (only uses `writeln`) and a more 
complex app that makes use of `std.algorithm` and such both at 
runtime and at compile time. Results:

Compilation time, ms (measured with Windows PowerShell 
`Measure-Command`):

|  | manual imports | `import essentials;` | `import std;` |
|-|-|-|-|
| hello world | 176 | 233 | 610 |
| test app | 411 | 410 | 738 |

File size, KB:

|  | manual imports | `import essentials;` | `import std;` |
|-|-|-|-|
| hello world | 262 | 262| 637 |
| test app | 327 | 327 | 663 |

I didn’t do more rigorous tests but this already looks very 
promising.

This also deals with namespace pollution, we are only importing 
the most common and well-known stuff from Phobos.
May 15
next sibling parent zjh <fqbqrr 163.com> writes:
In your way, one more step is enough,
And import STD is too funny to be added.
May 15
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Saturday, 15 May 2021 at 11:25:33 UTC, Ogi wrote:
 DMD 2.086.0 introduced `import std`. This is very convenient 
 for scripts and small apps. The downsides are compile time, the 
 resulting file size, and pollution of global namespace.

 ...
 
 To try it out, I created a file that looks like this:

 ```
 module essentials;

 public {
 	import std.traits;
 	import std.range;
 	import std.algorithm;
 	import std.array;
 	import std.string;
 	import std.typecons;
 	import std.stdio;
 	import std.conv;
 	import std.format;
 	import std.exception;
 }
 ```
perfect idea for a DUB package /s
May 17
parent reply Ogi <ogion.art gmail.com> writes:
On Monday, 17 May 2021 at 09:09:07 UTC, Basile B. wrote:
 perfect idea for a DUB package /s
Is there a trivial way to use dub packages with rdmd?
May 17
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 17 May 2021 at 13:14:36 UTC, Ogi wrote:
 On Monday, 17 May 2021 at 09:09:07 UTC, Basile B. wrote:
 perfect idea for a DUB package /s
Is there a trivial way to use dub packages with rdmd?
There's no way to use dub packages with rdmd. If you'd want to that, you might as well use dub.
May 17
parent Mike Parker <aldacron gmail.com> writes:
On Monday, 17 May 2021 at 13:38:24 UTC, Mike Parker wrote:
 On Monday, 17 May 2021 at 13:14:36 UTC, Ogi wrote:
 On Monday, 17 May 2021 at 09:09:07 UTC, Basile B. wrote:
 perfect idea for a DUB package /s
Is there a trivial way to use dub packages with rdmd?
There's no way to use dub packages with rdmd. If you'd want to that, you might as well use dub.
At least in terms of having everything automated. The only option is to clone the repository of any dub project you'd like to use and make sure its source is on the import path.
May 17
prev sibling parent reply Martin Tschierschke <mt smartdolphin.de> writes:
On Monday, 17 May 2021 at 13:14:36 UTC, Ogi wrote:
 On Monday, 17 May 2021 at 09:09:07 UTC, Basile B. wrote:
 perfect idea for a DUB package /s
Is there a trivial way to use dub packages with rdmd?
`https://dev.to/btbytes/you-dont-need-no-stinking-projects-dub-version--476c` Not the same, but the hint might help?
May 17
parent reply Ogi <ogion.art gmail.com> writes:
On Monday, 17 May 2021 at 15:27:53 UTC, Martin Tschierschke wrote:
 On Monday, 17 May 2021 at 13:14:36 UTC, Ogi wrote:
 On Monday, 17 May 2021 at 09:09:07 UTC, Basile B. wrote:
 perfect idea for a DUB package /s
Is there a trivial way to use dub packages with rdmd?
`https://dev.to/btbytes/you-dont-need-no-stinking-projects-dub-version--476c` Not the same, but the hint might help?
One problem with this solution is that dub doesn’t cache the executable when used this way. The point I am trying to make is that `import std` is not optimal for its intended use case. We should probably deprecate it if we get `std.essentials`.
May 20
next sibling parent zjh <fqbqrr 163.com> writes:
+10086.
May 20
prev sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 20 May 2021 at 12:42:56 UTC, Ogi wrote:
 On Monday, 17 May 2021 at 15:27:53 UTC, Martin Tschierschke 
 wrote:
 On Monday, 17 May 2021 at 13:14:36 UTC, Ogi wrote:
 On Monday, 17 May 2021 at 09:09:07 UTC, Basile B. wrote:
 perfect idea for a DUB package /s
Is there a trivial way to use dub packages with rdmd?
`https://dev.to/btbytes/you-dont-need-no-stinking-projects-dub-version--476c` Not the same, but the hint might help?
One problem with this solution is that dub doesn’t cache the executable when used this way. The point I am trying to make is that `import std` is not optimal for its intended use case. We should probably deprecate it if we get `std.essentials`.
No, we should improve the build times of `import std`, until it performs better than your proposed version of `import std.essentials` :P There's no fundamental reason why unused imports should be that slow. Here's a few pull requests that improved the compile times: https://github.com/dlang/phobos/pull/5931 https://github.com/dlang/phobos/pull/6122 https://github.com/dlang/phobos/pull/8053 There's a ton insightful discussion in in the PR that added the `std` package, e.g. starting with this comment: https://github.com/dlang/phobos/pull/5916#issuecomment-362870018
May 20
parent reply Ogi <ogion.art gmail.com> writes:
On Thursday, 20 May 2021 at 15:25:58 UTC, Petar Kirov 
[ZombineDev] wrote:
 No, we should improve the build times of `import std`, until it 
 performs better than your proposed version of `import 
 std.essentials` :P
This will not solve the problem with surprise imports.
May 20
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Friday, 21 May 2021 at 06:31:53 UTC, Ogi wrote:
 On Thursday, 20 May 2021 at 15:25:58 UTC, Petar Kirov 
 [ZombineDev] wrote:
 No, we should improve the build times of `import std`, until 
 it performs better than your proposed version of `import 
 std.essentials` :P
This will not solve the problem with surprise imports.
That's a good point, though this is a general problem with non-selective imports of large modules / packages and not specific to `std`. My guess is that [`import vibe.d;`][0] / [`import vibe.vibe;`][1] exhibits a similar problems. IMO, certain symbols (like the aforementioned `std.compiler.name`) are only meant to be available via static imports. Which brings me to the question: why does `static import std;` not work? I logged [issue 21943][2]. This prevents all possible accidental name collisions with non-`static` imports. Also it should make compilation faster, since the compiler knows the exact file name where to search for the given symbol, similar to the [self-important lookup idiom][4]. Anyway, I would expect that we can mark certain `public imports` in the `std` package as `static` (e.g. [this one][3]), which should make them available only through their FQN. Also `static import std.stdio : writeln;` should work by allowing to use `writeln` directly while `File` only via FQN - `std.stdio.File`. Said all that, I think `std.essentials` is a good idea! (I'm just against deprecating `std`, as it is a sound feature, which the language and Phobos should fully support.) We should provide an opinionated selection of the most commonly used Phobos modules, that also best represent the language (e.g. not things like `std.demangle`, `std.signals`, `std.system` which are unlikely to be used often). After checking your list again, the only change I would do is to add `std.{json,file,path,process,sumtype}` and `std.parallelism : parallel`, as these are things I use in almost every script. [0]: https://github.com/vibe-d/vibe.d/blob/v0.9.3/source/vibe/d.d [1]: https://github.com/vibe-d/vibe.d/blob/v0.9.3/source/vibe/vibe.d [2]: https://issues.dlang.org/show_bug.cgi?id=21943 [3]: https://github.com/dlang/phobos/blob/v2.096.1/std/package.d#L39 [4]: https://dlang.org/blog/2017/02/13/a-new-import-idiom/
May 21