arsd users: weigh in on proposed breaking change

[H. S. Teoh]

On Mon, Dec 19, 2022 at 08:57:26PM +0000, Adam D Ruppe via Digitalmars-d wrote:
> 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.

Well I know what `dmd -i` does. :-P  What I had in mind was something
more radical: importing a module would *not* trigger inclusion of the
entire module's code; only the parts that are actually referenced.  Say
module M contains functions A, B, C, each of which references symbols X,
Y, Z, respectively, in modules J, K, L.  As it currently stands, if you
import X, then `dmd -i` will also import J, K, L for you.  However, if
you only call X.A, then in theory the symbols from K and L will never
actually get used.  In my ideal vision, K and L would *not* be imported
in this case.

Now, today this can already be done to some extent by moving the imports
of J, K, L into the respective function bodies as local imports, and
making them template functions.  This however only works for templates,
and isn't scalable to the case where module M contains multiple
functions that import the same module; in that case it's probably better
to move the import to module level instead of repeating the import
inside every function that might need it.  And if you can't use template
functions for whatever reason, you're also stuck.

An even more extreme (and probably impractical) extension of this the
elimination of code paths that can be determined at compile-time never
to execute. E.g., most programs would not need all of the format
handlers inside writefln(). If you never need to format a float, then
the float-formatting part of writefln()'s implementation is just dead
weight and ought to be eliminated.  I don't think the current
implementation of format() is capable of doing this (the implementation
inside is a hairball of interdependent pieces that are almost impossible
to extricate independently).


[...]
> 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).
[...]

In an ideal world, there would be a list of symbols touched by the
module ctor, and if the reference graph containing these symbols is
disjoint from main(), then the corresponding code can also be elided.


T

-- 
MS Windows: 64-bit rehash of 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand 1-bit of competition.