On Thursday, 24 August 2017 at 18:12:03 UTC, H. S. Teoh wrote:
On Thu, Aug 24, 2017 at 06:00:15PM +0000, Jonathan Marler via
Digitalmars-d wrote:
On Thursday, 24 August 2017 at 17:49:27 UTC, H. S. Teoh wrote:
> Uh, no. This will definitely break separate compilation,
> and some people will be very unhappy about that.
I couldn't think of a case that it would break. Can you share
the cases you thought of?
Suppose you have main.d and module.d, and you want to compile
them separately:
dmd -c main.d
dmd -c module.d
dmd -ofmyprogram main.o module.o
If dmd defaulted to auto-importing, then `dmd -c main.d` would
also compile module.d (assuming main.d imports `module`),
contrary to what was intended in a separate compilation
scenario, and the last command will produce a linker error from
duplicated symbols.
This is just a simple case, of course. But in general, changing
the meaning of `dmd -c source.d` will break existing build
scripts. Sure, you could ask people to update their build
scripts to include `-no-auto-imports`, but that requires effort
from users, who will be unhappy that upgrading dmd broke their
build scripts. For large projects, such a change may not be
trivial as in the above example.
T
Actually this feature is mutually exclusive with the "-c" case.
It doesn't make sense to compile imported modules unless you are
also linking an executable. So your example would work as
expected.
Do you have any other cases you thought of that would not work?
Like I said I couldn't think of any. I'm not saying that that's
enough reason to make it an "opt-out" feature, it's just
something to think about. The feature could also be an "opt-in"
feature at first and eventually made "opt-out" if it makes sense.
But I'd still like to know people's thoughts/concerns either way.