April 29, 2019 std/package.d - better unittests | ||||
---|---|---|---|---|
| ||||
Looking through the std/package.d unittests, it seems too prone to mistakes. There is currently nothing in place to make sure that `import std` actually does import all of the modules in the standard library. I threw together a quick unittest that checks to make sure that all standard library modules are imported by std/package.d: (diff) https://pastebin.com/v1EnyZ53 (warning: very hacked-together) I ran it, and got these results: std.typetuple is not imported in std.package. std.xml is not imported in std.package. std.outbuffer is not imported in std.package. Is there a reason that these are not imported, or is it just accidental? I think there should be an additional unittest added to std.package that checks like this to prevent mistakes when new modules are added to phobos. Thoughts? |
April 29, 2019 Re: std/package.d - better unittests | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anonymous | On Monday, 29 April 2019 at 22:41:31 UTC, Anonymous wrote: > I ran it, and got these results: > > std.typetuple is not imported in std.package. > std.xml is not imported in std.package. > std.outbuffer is not imported in std.package. > > Is there a reason that these are not imported, or is it just accidental? Yes, there's a reason. All three are deprecated modules. std.typetuple is also not even documented anymore. You would never want to use any of these modules in your UFCS pipes. > I think there should be an additional unittest added to std.package that checks like this to prevent mistakes when new modules are added to phobos. It's a simple file. Modules in Phobos get added/changed _less_ than once a year, so imho it's not worth the cost of writing and maintaining this test file which is bigger than the file itself. |
Copyright © 1999-2021 by the D Language Foundation