220 41244 article Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Modules and preambule, just why? Date: Wed, 12 Dec 2018 13:15:23 +0100 Lines: 158 Approved: news@gmane.org Message-ID: References: <9f2c63e2-7904-49ea-a2ac-87e80fe78e78@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1544616838 1571 195.159.176.226 (12 Dec 2018 12:13:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 12 Dec 2018 12:13:58 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD3NR2WQQ4IBBAPYYPQAKGQEL7OQWMY@isocpp.org Wed Dec 12 13:13:54 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk1-f197.google.com ([209.85.221.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gX3Oh-0000I3-TG for gclcip-std-proposals@m.gmane.org; Wed, 12 Dec 2018 13:13:52 +0100 Original-Received: by mail-vk1-f197.google.com with SMTP id d123sf4020710vka.4 for ; Wed, 12 Dec 2018 04:16:02 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1544616962; cv=pass; d=google.com; s=arc-20160816; b=uDj5racSrAFmVmwi5WXevg/7nd2Vt+jmaybC0fRgCzLncUYbLdDMILpAxpfoz8tT7E eYDSXQcQxujSLjvMxsCppxL0khrokXtUg5x4HSpTlPH0QfyqwHaXmaVuX1p9eQ1/Pdtj to8KaBZkIHSAq1LoEYR+RWNTMfp/58PgOPATarRKD0LGZ36NZCgsU1XIhTKaHhOcjOGM fRbQW3CW4M86czFwJbeeyUf/uj+n1xUsUKLZfM8kuuzfZ6mUfFUhgYUdrZittQTbvgKi utmsRwtFRP1HCLCcjR5FrCuX1mnRaMZk72PHHGCKhojdx9+fE00Xto3ByNlxHeGdu3YE tJPg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:content-transfer-encoding :to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=HEhe56gjwRWKdiJpXFvtzu3YAlaKYNssqm20XXVyVvE=; b=w/j2qYU6caG8mgLeSaaYwEPP86xJpkTM/2G6abkbCUcVYPyYttzDNjgxWNEeK/pHid XoB1gQwZuaVzDMWsDk+8t+0bzhTnTDQAC3vBkgCtnqaasDEiYDZQG2xRxwGiEC0rpA6r +bMbwvPqmooEa5K7S3rI07HIqcbHuex90QdueFDWQWCQW1pKkUF5qM9vXsSXLH8Yq3g0 6SNXx1RGIQFTpG8rjJi38tV2FFAlsXkeGAnHfVSAHWPHGtEUZNBIWbmxcgrY6AEd8vvY K+XmMfFOhrG+cu3Cegb75GcP2MOplpSDs9fW/krnbeWDm3I3hOk2iW0V7OGWTh3Ft82Y 76jg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PkglixEC; spf=pass (google.com: domain of mjklaim@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=mjklaim@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=HEhe56gjwRWKdiJpXFvtzu3YAlaKYNssqm20XXVyVvE=; b=N8EXbVqwt1JHom7iosXhxLrLTz0CqA3TJu0StBtD8NfSCPSppTSv1JVMq82BkXDdGn 1nKybw0NgfIKLGr1n+yL5VNoLZLPVFATEZ45E37aHs5aVKAB16Q+7/juK7+6ebFmqMm6 KgMoXyZ1R5tFcuVRAMScXEDoOmdC7l0Es96f+Q1GGVGHGDbhU/sE0L7YgwE+BlZTIMi2 +nyN0U0xkBeGJyF+iHCTB7lbILgGldiYYgG2mJyYOSgaqxW1vi2/FZXDyWrNEfZstpZh HbJ4uVMIixNbqfVKDr3Nlz3nLKlfSWTQskgKUlAaBIVxoA1KLzXoUKPqatCYioZwqurO bUSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=HEhe56gjwRWKdiJpXFvtzu3YAlaKYNssqm20XXVyVvE=; b=deP4NRg+IUA193mh1r6R2ZXDf0jhqNSFn7BcCpuoqqIvPBHyq3gyAqFuLPgyYKFlTA sYRg5il93CH8Lnvm0K5FECkxNJ60uH4/u5j4Aqw1bi1N7CKdpLHUidHkYSUyzf13PxXz zYUdbGryubPm82Gr9iDJ+EyYmwevRWJ7FH6lk+p97IfE14fvKWDjdDGdBHNl1PMh6OF/ ZVTNLeU+GYNFdbkbRxz1TUaYDJfbfwZy8KSPljqpm/C/Ipr6PWXd7SApcYodKdhwhMQX dxMHt3lVSnZTyjY7IRDtZXPMpnVcI+p5AWPcaWiodniNOWRxLNqq9RHXWax0nOnFVAGj Ino X-Gm-Message-State: AA+aEWZ0ZYC+VjR846FjJutfXyF0bSJfXCEXS1d+Pi/P0/o1yih3IiD+ 4Mb5GA6bccrquALZA3RpLffi+g== X-Google-Smtp-Source: AFSGD/VIfSKi1/WVFn+LkqLWXHlJVW+Z0DFkQgCLcTC8qIWawEENkRK78gJbX07VbHfRUBq45g9Y7A== X-Received: by 2002:a67:3f0f:: with SMTP id m15mr18402398vsa.44.1544616962121; Wed, 12 Dec 2018 04:16:02 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a1f:9d0f:: with SMTP id g15ls2717524vke.1.gmail; Wed, 12 Dec 2018 04:16:01 -0800 (PST) X-Received: by 2002:a1f:95d1:: with SMTP id x200mr8914026vkd.78.1544616961131; Wed, 12 Dec 2018 04:16:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544616961; cv=none; d=google.com; s=arc-20160816; b=lUJKAuDqlmz7aimxQXkAmvjoNsngVng785lkBS6bWD6pnQs/plW1E6XtVIeLee7TKZ 9eyui56CjRz+Nsocrhzy7lkHUVrAXZbZLotspRS/Kqs0vAh/Va0kublEPkdPvFO517Ab K36eynsGX9tkXGJwNVTg5XKY5f9U3d0A/yl8a03Oiyuh5WruU1+sx4lDcen0VNu9LWEE XYT/UY4TjT+jkTAMEccj5Ahx40GI+VImwFo7G7A7oX0+l7eaHZXPrDw7mBE1od44bHj1 nGxQlkgOJTjJNk8v+AJfahElDnbD8hflWiPYSPR5xlID54rfTeDSx89VSw3ux+0YIrdl UeVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=8nXCh2/sQ5O2zwDp2R3bG/JWtjJp4eD9e3jGfHS+KY0=; b=Js7qSkFVHs08KEdcSkMLs0zWDtnsM0Gg5SorKhAixV+wJe1h0mGM9w75ygl6Y+WTFV 0KhR8HR2OoV8weuq+px+s4q+YSYvA8ZFIyImENTJlclYbrFVxfkbV/hZCPpmw+YTfumL TpWes+5K6yhMBUutt4mt7bYv663H8DyKVOeU6l8/Bta5SP+xqilRybJRB12b5JCmRwOA P4JVp2+AhkhCnUNGdsxkXtBrV2ItLqoUenGBUGEetZQENJfcIKHt7D48QqS/DBTJ0qDG roGJ3oudZBWKLg0BdG3qlumD+883quTuoXSbDA5RSKqEOcpdeJ0/Tu/fEUbWbMaGdFQ7 lqVA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PkglixEC; spf=pass (google.com: domain of mjklaim@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=mjklaim@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id 128sor8348598vkm.53.2018.12.12.04.16.01 for (Google Transport Security); Wed, 12 Dec 2018 04:16:01 -0800 (PST) Received-SPF: pass (google.com: domain of mjklaim@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a1f:6bc8:: with SMTP id k69mr8770636vki.84.1544616960116; Wed, 12 Dec 2018 04:16:00 -0800 (PST) In-Reply-To: <9f2c63e2-7904-49ea-a2ac-87e80fe78e78@isocpp.org> X-Original-Sender: mjklaim@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PkglixEC; spf=pass (google.com: domain of mjklaim@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=mjklaim@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:41244 Archived-At: On Tue, 11 Dec 2018 at 23:06, wrote: > From this code, you can easily say that importing this file will import t= he declaration of the 2 structs, the first one being just a POD data type, = while the second will have a ctor from a std::string and also a method form= at with the given signature. > Note that in this example, the implementation of the ctor and the format = method could be in the same cpp file but don't require to, since the declar= ation of the class is enough. I am not sure I understand your point because the code you are giving as example is not a module nor is it exporting anything. Let's say that you add the `module blah;` line first, then this is not exporting anything without you explicitely adding `export` keyword in front of declarations or forward declarations or definitions. So I don't understand what you mean exactly. >> The problem we have today with headers is that everything >> in a header needs to be parsed, whether part of the actual >> interface of the library or not. > > > The idea here is to parse the file only once and to save the "visible" pa= rt of it in a specific file. Note that the standard don't say it should end up in a file. It's a representation stored somewhere. It could be a database of intermediate representation for example. > The next time this file will be imported, we could just extract the visi= ble part from the generated file (since the source file didn't change since= the other one was generated), avoiding then to re-parse the source. Not only that. In non-template cases the code have already been "compiled" so only it's name and interface are checked when importing. This means that it's not like having the declaration of such function (for example) copy pasted where you import, it's more like adding the name and/or signature of the function to a pool of available names. There is no syntactic collision possible, compared to headers. For templates, some optimization might be possible (apparently) but it's still implicitely inline code so whatever goes. In any way, importing templates is still "adding names to the pool of available names". Or you should think that way anyway. >> Modules give us control over what >> things are part of the interface and what things are not. > > > Yeah, something in my approach is more or less missing here. More or less= I said? Yes, because in fact this partially already exists. I mean, take t= his code for example: > > //sample_details.cpp > > static void print_message(std::string& msg, const event& ev) > { > msg.append(ev.message); > } > > Here you know that the method print_message won't be exported by the comp= iler, and thus non-visible outside of the sample_details.cpp file. Even if = you import this file (which shouldn't be done if we take the logic of my ex= ample into account), this method won't be imported because it is internal t= o the sample_details.cpp file. > In fact, this mechanism is inherited from C, meaning that it exists from = a long time. But unfortunately, it use the static keyword, which could have= different meanings when used inside a class. Perhaps deprecating the use o= f static in this context and replacing it by something else (say internal f= or example) could do the trick. > Here you are describing symbol visibility which is orthogonal to what modules does, though if you mark a functions static it cannot be exported through modules (if my memory is correct). There are big differences. If your static function is part of a module, then it also mean that other modules can have the same functioon name in them, even if they end up compiled in the same binary (ODR is not violated because this function is identified as owned by the module, so can be differenciated from another function with same name and same signature and same namespace but ownd by another module). Module ownership is unrelated to symbol visibility, but it's maybe hard to see the nuance. To be short, let's say this code is in a module. That you put a static or not in front of it, as long as you didn't export this function, it's owned by the module and not exported, therefore nobody can "compile" with it. If someone does a declaration in their cpp file of such function which is owned by a separate module, my understanding is that it will end in a link error as the function in the module and the function declared will not be considered the same, because one is owned by a module and the other is owned by the global module. If the user code was in a module, then doing a declaration of such function makes this name owned by the user module, not the module you expect to import. So modules add another layer of fine-grained control over what can or not be accessed, but based on available names, while this example you gave isolates a function by making it not visible at link-time (through object files interface (I'm not sure how it's called)). For this specific example, the difference might not be obvious. ^^ > So i just give you a small example of how I saw things, but there are pro= bably a lot of related problems which need to be resolved, for example how = template should be handled when using this model. I didn't try to solve all= this since my goal is just to make you understand what I mean by "an appro= ach where the exported symbols are deduced from the code". Also I believe t= hat most of the choice made for the module proposal could apply to this mod= el as well. > Templates are simple with modules because they are not special: exported template names are visible from user code that imported the module. // mymodule.mxx export module mymodule; template auto foo(T value) { return value;} // not exported export template auto bar(T value) { return foo(value); } // export= ed // usercode.cpp import mymodule; void lol() { int x =3D foo(42); // ERROR: foo does not exist (it is not in the available names) int y =3D bar(0); // ok, bar is from module `mymodule` } Then in term of compilation+linking, this basically means that it is possible for compilers to process templates in a form maybe useful for some optimization. As importing will only add names to the pool of available names, importing don't imply (as you understood before) re-parsing the template. Which is already a big win in our current heavily templated C++ world. A. Jo=C3=ABl Lamotte --=20 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 e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/CAOU91OP5vDkST9iU3DCnTrVuZYxo59PJ_36-BzaBeyZs1tU= KRA%40mail.gmail.com. .