> And it breaks users who don't even have multiple mounts

I think we're in agreement on this, at least. If/when I make a second
draft it will be with a filesystem-based definition for uniqueness. I
realize this is closer to existing practice anyway, and I buy that the
definition is easier to reason about and make assurances about.

Jeremy


On Thu, Aug 29, 2024 at 9:15 PM Ville Voutilainen
<ville.voutilainen_at_[hidden]> wrote:
>
> On Fri, 30 Aug 2024 at 02:29, Jeremy Rifkin via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > > #include "library2/public.hpp" # boom, library2/utils.hpp does not get included
> >
> > This has already been presented. While I have shared I think this is
> > rare and such a "main header" should not use include guards in the
> > first place, it is compelling.
> >
> > In case it's not already abundantly clear: A content-based definition
> > is the only way to make #pragma once work for a setup like yours with
> > multiple mounts. But perhaps such a feature shouldn't bend over
> > backwards to support such a case.
>
> Except content-based definition doesn't make it work for a setup like
> Gasper's, because
> it will slow down the builds compared to using include guards. And it
> breaks users who don't
> even have multiple mounts. So the proposed content-based definition
> doesn't solve the problems
> people already have, and it introduces problems for other people too.
>
> That doesn't sound viable.