digitalmars.D - Global import of modules
- ryuukk_ (8/8) Mar 30 2022 https://forum.dlang.org/post/csnqfrweyiplmuhofojw@forum.dlang.org
- Petar Kirov [ZombineDev] (8/16) Mar 31 2022 I had a brief look at your PR and I think that indeed something
- user1234 (6/14) Mar 31 2022 I think it's bad because in theory that can break 3rd part
- Petar Kirov [ZombineDev] (27/46) Mar 31 2022 If we're serious about pay-as-you-go runtime/stdlib, perhaps
- ryuukk_ (5/24) Apr 02 2022 It wouldn't break anything, you can always import library modules
https://forum.dlang.org/post/csnqfrweyiplmuhofojw forum.dlang.org That is a nice idea, but i think it is better if it is supported by the compiler directly, so even if you don't use dub, you get to use the feature dmd hello.d --global-module=first.d,second.d,third.d This would allow me to do that: https://github.com/dlang/druntime/pull/3790 What is everyone's opinion?
Mar 30 2022
Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> On Thursday, 31 March 2022 at 06:47:46 UTC, ryuukk_ wrote:https://forum.dlang.org/post/csnqfrweyiplmuhofojw forum.dlang.org That is a nice idea, but i think it is better if it is supported by the compiler directly, so even if you don't use dub, you get to use the feature dmd hello.d --global-module=first.d,second.d,third.d This would allow me to do that: https://github.com/dlang/druntime/pull/3790 What is everyone's opinion?I had a brief look at your PR and I think that indeed something like `--global-module`, or rather `--prelude` [[¹]][1] [[²]][2], is the right way to go. Hopefully, that would allow to remove the hard-coded logic concerning `object.d` from the compiler by simply adding `--prelude=../include/dmd/object.d` to `dmd.conf`. [1]: https://wiki.haskell.org/Prelude [2]: https://doc.rust-lang.org/beta/reference/names/preludes.html
Mar 31 2022
On Thursday, 31 March 2022 at 06:47:46 UTC, ryuukk_ wrote:https://forum.dlang.org/post/csnqfrweyiplmuhofojw forum.dlang.org That is a nice idea, but i think it is better if it is supported by the compiler directly, so even if you don't use dub, you get to use the feature dmd hello.d --global-module=first.d,second.d,third.d This would allow me to do that: https://github.com/dlang/druntime/pull/3790 What is everyone's opinion?I think it's bad because in theory that can break 3rd part libraries. object.d is special, it's a fair exception, it's the runtime. Everything else should use imports + modules to have names resolved consistently.
Mar 31 2022
On Thursday, 31 March 2022 at 08:45:45 UTC, user1234 wrote:On Thursday, 31 March 2022 at 06:47:46 UTC, ryuukk_ wrote:If we're serious about pay-as-you-go runtime/stdlib, perhaps libraries should be required to explicitly import the things they use from druntime? This could be an opt-in breaking change, say `--preview=pay-as-you-go-runtime`. I think that would be an improvement over the current status quo of all or nothing (betterC). How about the following: * applications/libraries can opt-in to using pay-as-you-go runtime * to do so, they need to define their own `prelude.d` file * if it's empty that would be roughly the same as using the `-betterC` compiler flag * `prelude.d` publicly imports the parts of druntime/phobos (or a custom runtime for embedded devices) that the library needs * if a library doesn't use exceptions, it will simply not import `Throwable`, `Exception`, `Error` and related functions. * if it needs `ModuleInfo`, but not `TypeInfo`, it will only import `ModuleInfo` * and so on * The build system of the library will pass `--prelude=./src/prelude.d` to the compiler * E.g. in `dub.sdl` this could be `preludeModules "src/prelude.d"` * The `--prelude` option affects only the current compilation unit - applications or other libraries that depend on library A can each have their own prelude, and library A's prelude won't affect them and vice-versa.https://forum.dlang.org/post/csnqfrweyiplmuhofojw forum.dlang.org That is a nice idea, but i think it is better if it is supported by the compiler directly, so even if you don't use dub, you get to use the feature dmd hello.d --global-module=first.d,second.d,third.d This would allow me to do that: https://github.com/dlang/druntime/pull/3790 What is everyone's opinion?I think it's bad because in theory that can break 3rd part libraries. object.d is special, it's a fair exception, it's the runtime. Everything else should use imports + modules to have names resolved consistently.
Mar 31 2022
On Thursday, 31 March 2022 at 08:45:45 UTC, user1234 wrote:On Thursday, 31 March 2022 at 06:47:46 UTC, ryuukk_ wrote:It wouldn't break anything, you can always import library modules with a scope import stuff = my.awesome.thing; stuff.do(); // do your thinghttps://forum.dlang.org/post/csnqfrweyiplmuhofojw forum.dlang.org That is a nice idea, but i think it is better if it is supported by the compiler directly, so even if you don't use dub, you get to use the feature dmd hello.d --global-module=first.d,second.d,third.d This would allow me to do that: https://github.com/dlang/druntime/pull/3790 What is everyone's opinion?I think it's bad because in theory that can break 3rd part libraries. object.d is special, it's a fair exception, it's the runtime. Everything else should use imports + modules to have names resolved consistently.
Apr 02 2022