We already have something similar: pragma link. Since it exist, we can't
leave it out of the discussion.

That pragma is not widely used and is not a satisfactory solution for two
reasons: it doesn't convey proper usage requirements for that library, and
also it is not compatible with our build systems.

You seem to offer a potential pathway to solve the first point, but what
about the second? How will your solution to make "C++ a million times
better" solve the second point?

There's a few things that need to be answered so that this thing becomes
compatible with buildsystems:

- How can you communicate to the build system when to rebuild? Usage
requirements may change, the library linked to might also change. You need
to forward this to the build system in a way that would be optimal. This
needs to be specified.

- How do you write those usage requirements? This is something important
because all code compiled into a library will need to do this, not just
system libraries

- Where do you find those usage requirements? System libraries can be found
easily but there might be multiple prefixes an probably one prefix per
project if you're using a package manager.

- You solution seems to apply TU by TU. This is not how modern build
systems are architectured. Modern build systems work on target basis, and
the target itself expose usage requirements. Preferably, I would write
usage requirements once per targets instead of once per file. It could also
be module per module basis if you clearly explain the limitations and
advantages of doing this.

- Speaking of modules. How will this feature work with them and will it be
a modules only feature?

- Some buildsystems have what they call interface targets. A target
consisted of only usage requirements without having a byproduct or any
files to compile. Would there be a way to specify those?

Many of those things are solved by modern build systems and package
managers. For us, or at least me, to understand the solution you're
proposing, it's important that we discuss of those details and how they
will work with current build systems.

Em dom., 19 de fev. de 2023 05:15, Andrew Tomazos via Std-Proposals <
std-proposals_at_[hidden]> escreveu:

> I don't really understand your suggestion, but I suspect you should take a
> look at the conan package manager if you haven't already:
> https://conan.io
>
> On Sun, Feb 19, 2023 at 6:22 PM Matthew Groom via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Hello
>>
>> This suggestion with improve C++, a million times.
>> This suggestion allows compilers to change their settings based on tags
>> in the file itself.
>>
>> Have a single cpp file, in it have tags at the top as square brackets,
>> that tell the compiler every link, change it needs to do to run that
>> program.
>> [dx12]
>> E.g. This tag will allow a compiler to change all its settings and set
>> the file up as a dx12 program, all the libraries are brought in and linked
>> etc.
>> It is such a simple change, but every developer will thank you a million
>> fold.
>>
>> This is what this will accomplish, every time you load the file, the
>> compiler sets up its environment and all you have to do is press run, its
>> that simple.
>> No more messing around with reading comments about you must link this
>> library, include this file. Its all done with a tag.
>>
>> Also you don't need header files anymore, stick it all in the same file
>> as a tag, that way this new version is backwards compatible.
>>
>> The only reason header files were invented is it allowed you to view the
>> functions, it is no longer needed with IDE's that can expand and contract
>> section so you can see or not see a section of code in the IDE. You can
>> remove header files now and put them in the file itself or remove them
>> completely.
>>
>> Lets have, one file, one place, one configuration for the IDE, one happy
>> community.
>>
>> As things get more complex it is MORE important the IDE knows how to
>> handle a file, what to load and not load and configure itself.
>>
>> Regards
>> Matthew Groom
>> mattgroom_at_[hidden]
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>