Should require and provide be symmetrical?

[Stephen J. Turnbull]

Nathaniel Flath writes:

 > I came across a problem with require and provide that seems rather
 > counterintuitive, although it is implicit in the documentaiton.  If one file
 > provides a feature with (provide 'feature) and another requires it, there is
 > no guarantee that that specific file is loaded, even if no other file calls
 > (provide 'feature).

How do you propose that Emacs would know this?  N.B. In general there
are usually at least two files that provide any feature (the .el and
its corresponding .elc).

 > I ran into this whil splitting up my personal configuration - I was
 > attempting to mirror the packages I was loading, so for example
 > org.el in my directory would contain customizations for org-mode.
 > However, in this file, a (require 'org) would cause an infinite
 > require error, as it tried to load itself instead of the org.el in
 > emacs.  Should this behaviour be changed, or is there a reason for
 > it?

You'd have to change the loader to parse the file without loading it.
Yuck.  Then, if you get a provide error, you have to keep walking the
load-path to the very end in hopes of find one that does do a provide.
This is still (Big-O (length load-path)), but your coefficient has
been pessimized.  Yuck.  And now we have to maintain state for error-
reporting (a list of tried-and-failed org.el and org.elc files).
Double-yuck.

So, no, I can see no positive reason for the behavior, but I can see
lots of reasons not to change the implementation.  If I were you, I'd
just put those configs somewhere that isn't on load-path.