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?

On Thursday, 31 March 2022 at 06:47:46 UTC, ryuukk_ wrote:

I had a brief look at your PR and I think that indeed something like --global-module, or rather --prelude [¹] [²], 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.

On Thursday, 31 March 2022 at 06:47:46 UTC, ryuukk_ wrote:

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.

On Thursday, 31 March 2022 at 08:45:45 UTC, user1234 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.

On Thursday, 31 March 2022 at 08:45:45 UTC, user1234 wrote:

It wouldn't break anything, you can always import library modules with a scope

import stuff = my.awesome.thing;
stuff.do(); // do your thing