Prevents the import of object module when -dnostdlib has been passed

[ghost]

Depends on #10180

[dlang-bot]

Thanks for your pull request and interest in making D better, @ErnyTech! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + dmd#10184"

[marler8997]

Most of object.d is templated now, so if you don't use anything from object.d then it's really not doing anything. What's the reasoning for adding a command-line option to disable object.d?

[JinShil]

The problem is that the compiler automatically imports object.d. If it can't find it in the import path, DMD emits a compiler error. For the use case that this PR addresses, the user doesn't need object.d, but the user is forced to create an empty one just to keep the compiler from complaining.

[marler8997]

I wonder if it would be better to allow the source to specify this in some way? Maybe through a pragma? pragma(noObjectModule)? Or, since I believe that the compiler already parses the module declaration before inserting the object module, we could add something to the module declaration? module foo nobject;? Or we could use an attribute on the module declaration like @noobject module foo;.

[marler8997]

I've created an alternative solution here: #10188

PR #10184 instead added a new command-line switch to disable importing the object module. I created this one as an alternative because it's the source code that knows whether or not the object module should be imported. This solution is less brittle as the one compiling the module doesn't need to know whether or not the command-line switch is needed. It also allows the compiler to compile both kinds of modules in the same invocation since each module configures itself instead of having one global configuration for every module.

[Geod24]

Having a standard module with definitions such as alias size_t = (void*).sizeof; or string is not inherently incompatible with a -dnostdlib. So IMO they should not be conflated.

[marler8997]

Having a standard module with definitions such as alias size_t = (void*).sizeof; or string is not inherently incompatible with a -dnostdlib. So IMO they should not be conflated.

I think most things in object.d really don't do any harm which was the point that @andralex brought up. Most things in object.d are already pay for what you use. It's not all there yet but I think it can be at some point. The only use case I've heard for removing the object.d import is when you don't need/want it and you don't want to create an empty one.

[WalterBright]

The need for such a feature is so specialized that the programmer doing it shouldn't have any difficulty creating a dummy object.d with nothing in it to import.

I don't think this feature pulls its weight.