digitalmars.D - std.essentials
- Ogi (50/50) May 15 2021 DMD 2.086.0 introduced `import std`. This is very convenient for
- zjh (2/2) May 15 2021 In your way, one more step is enough,
- Basile B. (2/23) May 17 2021 perfect idea for a DUB package /s
- Ogi (2/3) May 17 2021 Is there a trivial way to use dub packages with rdmd?
- Mike Parker (3/6) May 17 2021 There's no way to use dub packages with rdmd. If you'd want to
- Mike Parker (4/11) May 17 2021 At least in terms of having everything automated. The only option
- Martin Tschierschke (3/6) May 17 2021 `https://dev.to/btbytes/you-dont-need-no-stinking-projects-dub-version--...
- Ogi (6/13) May 20 2021 One problem with this solution is that dub doesn’t cache the
- zjh (1/1) May 20 2021 +10086.
- Petar Kirov [ZombineDev] (13/29) May 20 2021 No, we should improve the build times of `import std`, until it
- Ogi (3/6) May 20 2021 This will not solve the problem with surprise imports.
- Petar Kirov [ZombineDev] (36/42) May 21 2021 That's a good point, though this is a general problem with
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 2021
zjh <fqbqrr 163.com> In your way, one more step is enough, And import STD is too funny to be added.
May 15 2021
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 2021
On Monday, 17 May 2021 at 09:09:07 UTC, Basile B. wrote:perfect idea for a DUB package /sIs there a trivial way to use dub packages with rdmd?
May 17 2021
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:There's no way to use dub packages with rdmd. If you'd want to that, you might as well use dub.perfect idea for a DUB package /sIs there a trivial way to use dub packages with rdmd?
May 17 2021
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: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.On Monday, 17 May 2021 at 09:09:07 UTC, Basile B. wrote:There's no way to use dub packages with rdmd. If you'd want to that, you might as well use dub.perfect idea for a DUB package /sIs there a trivial way to use dub packages with rdmd?
May 17 2021
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:`https://dev.to/btbytes/you-dont-need-no-stinking-projects-dub-version--476c` Not the same, but the hint might help?perfect idea for a DUB package /sIs there a trivial way to use dub packages with rdmd?
May 17 2021
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: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`.On Monday, 17 May 2021 at 09:09:07 UTC, Basile B. wrote:`https://dev.to/btbytes/you-dont-need-no-stinking-projects-dub-version--476c` Not the same, but the hint might help?perfect idea for a DUB package /sIs there a trivial way to use dub packages with rdmd?
May 20 2021
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: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-362870018On Monday, 17 May 2021 at 13:14:36 UTC, Ogi wrote: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`.On Monday, 17 May 2021 at 09:09:07 UTC, Basile B. wrote:`https://dev.to/btbytes/you-dont-need-no-stinking-projects-dub-version--476c` Not the same, but the hint might help?perfect idea for a DUB package /sIs there a trivial way to use dub packages with rdmd?
May 20 2021
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` :PThis will not solve the problem with surprise imports.
May 20 2021
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: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/No, we should improve the build times of `import std`, until it performs better than your proposed version of `import std.essentials` :PThis will not solve the problem with surprise imports.
May 21 2021