arsd users: weigh in on proposed breaking change

Mon Dec 19 20:57:26 UTC 2022

On Monday, 19 December 2022 at 20:18:54 UTC, H. S. Teoh wrote:
> On that note, though, it would be nice if D had some kind of 
> feature where only actual dependencies end up in the 
> executable, i.e., end-to-end pay-as-you-go.

It does, and it has for over five years now! This is the only 
reason why this change is even on the table at all.

This is what `dmd -i` does. Only things actually imported are 
compiled at all. Then you keep your imports local in templates 
which means they now happen on function-level granularity.

So for example, if you do

---
import arsd.dom;

void main() {
    auto document = new Document("<html></html");
}
---

And then `dmd -i yourapp.d`, it will automatically pull in 
arsd.dom to the build... but not the rest of the arsd modules.

Now change it to:

---
import arsd.dom;

void main() {
    auto document = new Document();
    document.parseGarbage("<html></html");
}
---

And the same `dmd -i yourapp.d` will now automatically pull in 
arsd.dom and arsd.characterencodings because parseGarbage uses 
that to convert things to utf8.

Or try:

---
import arsd.dom;

void main() {
    auto document = Document.fromUrl("http://dlang.org/");
}
---

And again, the same `dmd -i yourapp.d` will pull arsd.dom, 
arsd.characterencodings, and arsd.http2 automatically, again 
because it knows you called fromUrl which imports arsd.http2.

It took a little bit of effort for me to write the code in a way 
to do all this correctly, but the compiler works with it.

The linker can also further strip unreferenced things from the 
executable afterward, and if you're careful about your import 
web, this can be very effective (and it sometimes can be too even 
if you aren't careful, but any module constructors being present 
have a habit of defeating the linker's stripping since it can't 
know if it is actually necessary or not).

> We've been trying to make druntime/Phobos pay-as-you-go for 
> years, and still haven't come close to the ideal state yet.

That's because they wrote things very differently than I do. arsd 
explicitly avoids dependency webs - which is why adding this 
proposed `core.d` module would be a breaking change, since I need 
to make an exception to that policy (and like i said in a 
previous message, I did consider suspending that policy entirely, 
but I don't think I'm going to do that. One advantage of more 
modules is, when combined with `dmd -i`, you can get pretty 
granular on what is compiled in. Just this doesn't always 
actually bring you a win.)