Jump to page: 1 2
Thread overview
std.essentials
May 15
Ogi
May 15
zjh
May 17
Basile B.
May 17
Ogi
May 20
Ogi
May 20
zjh
May 21
Ogi
May 15

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

In your way, one more step is enough,
And import STD is too funny to be added.

May 17

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

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

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

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

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 20

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

+10086.

May 20

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

« First   ‹ Prev
1 2