From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13816 invoked by alias); 2 Nov 2010 10:07:30 -0000 Received: (qmail 13806 invoked by uid 22791); 2 Nov 2010 10:07:29 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,TW_BJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 02 Nov 2010 10:07:24 +0000 Received: from eggs.gnu.org ([140.186.70.92]:40739) by fencepost.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PDDlx-00048p-7G for gcc-patches@gnu.org; Tue, 02 Nov 2010 06:07:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PDDlt-0003d2-EQ for gcc-patches@gnu.org; Tue, 02 Nov 2010 06:07:21 -0400 Received: from c2beaomr08.btconnect.com ([213.123.26.186]:38741 helo=mail.btconnect.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PDDlt-0003cp-54 for gcc-patches@gnu.org; Tue, 02 Nov 2010 06:07:17 -0400 Received: from host81-138-1-83.in-addr.btopenworld.com (EHLO thor.office) ([81.138.1.83]) by c2beaomr08.btconnect.com with ESMTP id AMN23201; Tue, 02 Nov 2010 10:07:13 +0000 (GMT) Cc: "gcc-patches@gnu.org" Message-Id: From: IainS To: Nicola Pero In-Reply-To: <1288690926.829416922@192.168.2.230> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: ObjC/ObjC++: updated documentation on supported standards, and added -fobjc-std=objc1 Date: Tue, 02 Nov 2010 10:13:00 -0000 References: <1288690926.829416922@192.168.2.230> X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4CCFE2CB.0123, actions=tag X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.4CCFE2D1.0340,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-11/txt/msg00115.txt.bz2 On 2 Nov 2010, at 09:42, Nicola Pero wrote: > * adds a new -fobjc-std=objc1 option which causes the compiler to > accept only > the Objective-C 1.0 syntax (which for clarity of definition I > defined as the > Objective-C syntax accepted by GCC 4.0); as we've discussed before, I think this is a very good idea ... (we will also probably need an -fobjc-abi=) > The option name itself is not set in stone; suggestions I welcome. > I like > -fobjc-std=xxx (as opposed to, say, -fobjc-language-version=1 / - > fobjc-language-version=2) > for consistency with -std=xxx and because we don't know how future > versions of the language > may be named or presented so having a free string there helps to be > adaptable (in the same > way as it works for -std=xxx in C/C++). .. the only issue with using 'std' is that there are no 'standards' as such - on the NeXT side the best we could do would be to refer to the ObjC1 and ObjC2 documents and XCode release notes. I am not passionately worried by this - but would vote in favor of - fobjc-language= or even -fobjc-lang= ( to keep the typing to a minimum) An enumerated short string is much more flexible than a number. > About the short string used to mean 'Objective-C 1.0', I chose > 'objc1'. An alternative > would be choosing 'gcc40', so the option could become -fobjc- > std=gcc40. That may be > more accurate, but less obvious (or maybe not). This looks good and should encompass the pre-Darwin-9 language variant too. I'm not sure that naming by gcc release would help the User much - is there enough objc doc in the tree to be clear about what functionality is included? If we needed to make it more fine-grained, for NeXT the logical thing would be to name by XCode release - since then the documentation is available (in public). [but your present suggestion is perfectly good for current needs :-)] BTW, I also noticed that Darwin-8/NeXT cannot support object iterators (missing a function in the runtime). We might need a means to disable that. cheers, Iain