Re: #import future (summary and proposed solutions)

[Nicola Pero <nicola at brainstorm dot co dot uk>]

> > In fact, I don't understand how your solution would manage hard links.
> >
> > If /home/nicola/B.h is a hard link to /home/nicola/A.h (that is, they
> > have different names on disk, but they are the same inode/file), then
> >
> > #import "A.h"
> > #import "B.h"
> >
> > wouldn't work properly, because it would include the file twice (since
> > A.h and B.h have different paths on disk), while it should include it
> > only once, because they are the same file.
> 
> Wow, observing that #importing A.h and B.h also wouldn't work if they
> contained duplicate copies of the same file content would be nearly as
> profound; and nearly as irrelevant.

Why do you consider hard links irrelevant to the discussion ?

There are still people around using hard links (I suppose you'd use
symbolic links instead), even if they are getting rarer.  They're most
frequent in old-time unix programmers.

If you ask them, they usually claim some of the following as reasons to
use hard links instead of sym links - hard links are more portable, hard
links take up less disk space, hard links are faster to access, ...

Maybe these reasons are obsolete, maybe they are not.  But if the
filesystem supports hard links, and there are people using them, it's
relevant to consider what happens when a header is a hard link to another
one.