220 14689 article Path: news.gmane.org!not-for-mail From: Will Cassella Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Modules with lazy symbol resolution Date: Fri, 21 Nov 2014 20:15:57 -0800 (PST) Lines: 134 Approved: news@gmane.org Message-ID: References: <3384057.c619ZPUSbM@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_99_503115908.1416629757017" X-Trace: ger.gmane.org 1416629764 29868 80.91.229.3 (22 Nov 2014 04:16:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Nov 2014 04:16:04 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCNJLUGVSMKBB7U3YCRQKGQEPWS4K2I@isocpp.org Sat Nov 22 05:16:00 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vc0-f199.google.com ([209.85.220.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xs275-0006bR-HN for gclcip-std-proposals@m.gmane.org; Sat, 22 Nov 2014 05:15:59 +0100 Original-Received: by mail-vc0-f199.google.com with SMTP id le20sf4608609vcb.10 for ; Fri, 21 Nov 2014 20:15:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=4Sn/VaNmV5mevu2hcoYmtG4o+aPQ/uymEWbrqDLkoJ4=; b=nlKmdW3EnPzmXMLCP0zLPb9lNgbJNOQMTVgbcQhBEVXOrwa40zrFAFB6b92CgobanG 3GiJJA0iCAmETjp1FXiqj+g2wrSSGDCjWCPjMfeJqyP1s4I14uW+U9EePpbpu7rYEKSf TWuLkDC/EUFdxPrZvmDZXT6JFdxCtxTNuu7monRQL6kX5klXV2Kx5flMd+vfHjrDcJBf s08wwIQ2mc9QTZ93QHPDqppGzGtLVaAugYEP7IGbGlDvJe/BM0a8CxHeG4JN7bHMRmha 3QAioSH1JIZO4pixqYSW1Fo4K3enKoET/TPxhIDVsVXPnX6A9ZeNr563cugUQNhpXUKX xZWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=4Sn/VaNmV5mevu2hcoYmtG4o+aPQ/uymEWbrqDLkoJ4=; b=AVFC03OrIbYT2TljBkD6IOqavkqywo7v02AJkas/zrWQkeWcF+eISpab6llk1Ypxh5 rD+GHI6o46YzfLUzgZDaYJcqnNBLowwLdMWkt5jOqcClOWWZXuFgLaXBBjgGdCembThf R9e7qH1IzMslojLMwPbXHOSjXqVYG25IrmKFu3T1KiG+lrUSkuoJB3mHoRGlzOZx8wHC iCkDao0oGEWj69K62mkVlA7WSv/a0eRWXTJk5sduEm90l0UEisJ9rNx+TXaq/Bu3zbbw Y7RM6fvNoT7l5iLj+oRZtB6W+HAJKCLSndgOWJbj4XM/Z0mzDlFaOO+d8OLHG8iSUQ3T oMLg== X-Gm-Message-State: ALoCoQnTpy2He16Wsqg4/ToFB8/zsnqqySWTLUn+yxNrlQRsvbNIkBjRl8IUn0mOR7NyLRXeQ9MZ X-Received: by 10.236.2.41 with SMTP id 29mr6771489yhe.32.1416629758708; Fri, 21 Nov 2014 20:15:58 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.117.106 with SMTP id kd10ls155890igb.33.gmail; Fri, 21 Nov 2014 20:15:58 -0800 (PST) X-Received: by 10.50.118.9 with SMTP id ki9mr22925igb.16.1416629758071; Fri, 21 Nov 2014 20:15:58 -0800 (PST) In-Reply-To: <3384057.c619ZPUSbM@tjmaciei-mobl4> X-Original-Sender: wcassella@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:14689 Archived-At: ------=_Part_99_503115908.1416629757017 Content-Type: multipart/alternative; boundary="----=_Part_100_1225947517.1416629757017" ------=_Part_100_1225947517.1416629757017 Content-Type: text/plain; charset=UTF-8 Why not? I can see how C++ has quite a bit of momentum going with this, but it seems that removing the restriction of declaration-before-use would only make the language easier to use. It has been implemented successfully in other languages, so I don't see why c++ should be any different. Is there anything unique to C++ that prevents doing so? On Friday, November 21, 2014 9:05:17 PM UTC-7, Thiago Macieira wrote: > > On Friday 21 November 2014 18:01:38 Will Cassella wrote: > > I have been reading a lot about modules lately, and their potential use > in > > the future of C++. Personally I find the shift very appealing and am > > looking forward to seeing its implementation. My favorite approach to > the > > concept has been the one taken by the developers of Clang. However, one > > angle I have not seen explored is the possibility of lazy symbol > resolution > > (i.e allowing the usage of a type/function before its declaration) > within > > module compilation. > > I don't think this will ever happen. > > All functions need to be forward declared with their full parameter list > and > return types before they can be called or their address taken, all global > variables must be extern-declared before their address can be taken and > for > that all aggregates must be forward-declared. Additionally, before any > type > can be constructed, it needs to be fully declared. > > That is not going to change. > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > Software Architect - Intel Open Source Technology Center > PGP/GPG: 0x6EF45358; fingerprint: > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 > > -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_100_1225947517.1416629757017 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Why not? I can see how C++ has quite a bit of momentum goi= ng with this, but it seems that removing the restriction of declaration-bef= ore-use would only make the language easier to use. It has been implemented= successfully in other languages, so I don't see why c++ should be any diff= erent. Is there anything unique to C++ that prevents doing so?

On Fr= iday, November 21, 2014 9:05:17 PM UTC-7, Thiago Macieira wrote:On Friday 21 November 2014 18:01:38 Will = Cassella wrote:
> I have been reading a lot about modules lately, and their potentia= l use in=20
> the future of C++. Personally I find the shift very appealing and = am=20
> looking forward to seeing its implementation. My favorite approach= to the=20
> concept has been the one taken by the developers of Clang. However= , one=20
> angle I have not seen explored is the possibility of lazy symbol r= esolution=20
> (i.e allowing the usage of a type/function before its declaration)= within
> module compilation.

I don't think this will ever happen.

All functions need to be forward declared with their full parameter lis= t and=20
return types before they can be called or their address taken, all glob= al=20
variables must be extern-declared before their address can be taken and= for=20
that all aggregates must be forward-declared. Additionally, before any = type=20
can be constructed, it needs to be fully declared.

That is not going to change.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4= 5358

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_100_1225947517.1416629757017-- ------=_Part_99_503115908.1416629757017-- .