Re: RFC: FSF GCC, #import (and #pragma once)

[David Ayers]

Hi Adam,

Thanks for the reply!

Adam Fedor wrote:

> It's probably useful to at least make your opinion known. 

Yes, I just wanted to avoid GNUstep developers arguing amongst each 
other on GCC's list, rather than here.

> #import has been depreciated for some time (even by Apple) ...

I must admit, I was very surprised to hear this!  A quick search on 
Apple's pages did in fact reveal:
http://developer.apple.com/techpubs/macosx/DeveloperTools/gcc3/cpp/Obsolete-once-only-headers.html

"GCC permits the use of |#import| in C and C++ as well as Objective-C. 
However, it is not in standard C or C++ and should therefore not be used 
by portable programs."

and
http://developer.apple.com/techpubs/macosx/ReleaseNotes/GCC3.html :


     "Changes in Warnings

Some warnings are now off by default, but can be turned on again with a 
compiler switch. They are as follows:

The directives #pragma once and #import. GCC handles them correctly, 
even though they're *obsolete*. Use -Wpragma-once and -Wimport to see 
the warnings about them."

But these don't seems like a prominent deprecationby Apple.  The former 
seems like a advisory for dedicated implementation languages, yet 
ignores ObjC++, while the later is a release note bullet under the title 
of "Changes in Warnings".  They are more weak acknowledgements that they 
recognize the issues.  And most important of all, because they have not 
guarded their headers against multipleinclusion and continue to use 
#import within their headers themselves, it remains an academic 
discussion in relation to existing code base.  Do you, or anyone else, 
have a reference to a more prominentstatement?

In my view, before the FSF should consider removing the support for 
#import, Apple must guard their headers, (probably stop using #import 
themselves), prominently deprecatethe usage, and maybe even remove it 
from their version of GCC.  And even then, if FSF GCC still supported 
the (then old) Apple semantics of #import, the FSF might still consider  
continuing the support for a while just in case this might spur some 
projects to switch to GNUstep.  (I do recognize that in the real world 
Apple will most certainly not remove the feature as long as FSF GCC has it.)

I believe the technical implications, of whether this or that 
implementation is correct or not, is secondary to that fact that the FSF 
GCC should encourage the use of free software by implementing a widely 
used feature.  And this alone should cause the FSF to embrace the work 
of anyone syncing FSF's and  Apple's semantics, no matter how broken 
Apple's semantics might be.  This of course only applies to features 
that the FSF discourages anyway and are merely provided for 
compatibility, as is the case here.  And I have no problem if this 
potentially broken feature were turned off by default and must be 
enabled explicitly..

Cheers,
Dave