220 33028 <5d9edee7-e709-467f-bb9f-9001d5e2a421@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: gmisocpp@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: pre toronto mailing modules proposal Date: Thu, 29 Jun 2017 05:57:15 -0700 (PDT) Lines: 194 Approved: news@gmane.org Message-ID: <5d9edee7-e709-467f-bb9f-9001d5e2a421@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3417_724499250.1498741035230" X-Trace: blaine.gmane.org 1498741042 11697 195.159.176.226 (29 Jun 2017 12:57:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Jun 2017 12:57:22 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCM3TRNUXUDBBLHS2PFAKGQEQXVNF6Y@isocpp.org Thu Jun 29 14:57:18 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f71.google.com ([74.125.83.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dQZ0T-0002ZF-7h for gclcip-std-proposals@m.gmane.org; Thu, 29 Jun 2017 14:57:13 +0200 Original-Received: by mail-pg0-f71.google.com with SMTP id g7sf88873635pgp.1 for ; Thu, 29 Jun 2017 05:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=7X0gv19Ui9UgXnmlCoH7Ib/dsDTR9+qHPjhHODgQixo=; b=XAu1q7lkQ0WQ4gnrMsWiu2Oi/wAP2gSd1Q8vTnxMhEtdKcFhvEe/YyFEFt9MwXdOUj E1AX5n0xV5zCH1lu89LCT2eBkj9k8prrrRVePC7pPEfpZR8Ju4xiC10M+gBwFZF/GIpj LCooYBCFT/7ys1g6w7jneWR/C9wfFUy9SlVyPyRsYmoCgnUzotmIl2RlKUON4rEAvIQs sri420oxlbeaWjgZyZvKIq5Ghpvjiwakj8iHI18RljUmW2cc3svSz9Q4szRcpKIp6ISZ zVPi/YG8G4cexX2PNF1T1HITs8WHdcj62EcTgWrTSHeD1OUfXHpVFi7WLCt/rX+mETr2 fhsg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=7X0gv19Ui9UgXnmlCoH7Ib/dsDTR9+qHPjhHODgQixo=; b=btoVYavUpTa9qdTkf+uA1W+qIUF/q0m3j7Gt5eGr5CoXBYWBfLVpmzpEFHn0Rf6Wj5 vyAcUj2NmyUczHpdGbZBtclotwi04p5+cG8ubvqZkAii/x6kagDtod7XNITgLVxrarC7 D+DSZJ/OT/EZ76xcoSAA/RinKzvBr2Bdg+Y49hFEFCXOj379hDrt5aa9hSrgoIB2pCv+ 4qgPEdASQnyhsWLzB95jDY+saDKmT3CmTVw7txpela9CQi1KRI6ItTQ05TFEQlIAjFL7 Bw5YPJ2F87EQSDudsGdIisYeOk6JXOZZD5VELDsluFxENhNGPnpyhUXOcDW3j2meRFeo uX9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=7X0gv19Ui9UgXnmlCoH7Ib/dsDTR9+qHPjhHODgQixo=; b=jNd3IEFAQ6gM3vWbj2S57hCEeNBSGDoBPOElA9CmiEKkNQM8DZ5vjmdrZ3ZtxNCmkQ I+c6A1uJC+7dxx1rlt2tKLmTnxVqeJExP7ylvTk/C3benpkCB1XialFudE7jmXO7g+RB Z/HFMLquHTPUOBr1Ht2PxWvk9Bmq8r42ETycOuuNXCaUCerrsGPL+5tTg8w/OZv4r1FD 6yJukmdS7oWFYe6HB20uSwZBz1OteZfUFbrEiAKHe7TfHgg8ttlzW3/JMpsiGNQ6KdMx kHJ9BlnszL9BQS6MR5GZ7L+SKdGJnLyxI98b0jBnUhG4OafREDu7xQlH14U2SJTfpBLk 3i+w== X-Gm-Message-State: AKS2vOwh3jXm1Mi3gekymj9I9tcRsYjQQI8KahUyj53NqTPtSAkhBFPp QjLoLnp9dToXSDlq X-Received: by 10.99.232.83 with SMTP id a19mr9816098pgk.127.1498741038034; Thu, 29 Jun 2017 05:57:18 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.164.193 with SMTP id d62ls720795ioj.39.gmail; Thu, 29 Jun 2017 05:57:15 -0700 (PDT) X-Received: by 10.36.16.207 with SMTP id 198mr76324ity.1.1498741035738; Thu, 29 Jun 2017 05:57:15 -0700 (PDT) X-Original-Sender: gmisocpp@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:33028 Archived-At: ------=_Part_3417_724499250.1498741035230 Content-Type: multipart/alternative; boundary="----=_Part_3418_664593500.1498741035230" ------=_Part_3418_664593500.1498741035230 Content-Type: text/plain; charset="UTF-8" Hello Everyone I'm trying to follow the module proposals and the latest suggestions regarding them from the pre Toronto mailing. Could somebody please clarify how the latest modules proposal suggests we define a module? Is it like this: To create and use a module one needs to have a module interface and it's implementation, A module interface for a module named x can be defined by a single file containing a module x [[interface]] statement; OR A module interface can be defined by a group of files where each file contains a module x [[partition]] statement'; In the module definition file, they just announce the source that follows defines the module x by doing simply: module x; So if someone was going to define the STL via modules, they might do: // file: std_containers.vector.h module std_containers [[partition]] class vector { /* ... */ }; // file: std_containers.string.h module std_containers [[partition]] class string { /*...*/ } // file:std_containers.vector.cpp module std_containers; vector::vector() { } // file: std_containers.string.cpp string::string() { } // file: std_filesystem.h module std_filesystem [[interface]] class path { /* ... */ }; bool some_helper(); // file: std_filesystem.cpp export path::path() { } export bool some_helper(); // Then the user might use some compiler to compile like so: $ cc std_containers.cpp std_filesystem.cpp To create these files: std_containers.module_interface std_filesystem.module_interface std_containers.module_implementation; // could be a dll or so file or lib std_filesystem.module_implementation; // could be a dll or so file or lib Then they might create a user of this module like so: module_client.cpp import std_containers; // now string and vector exist import std_filesystem; // now path exists. // And compile it with some compiler cc module_client.cpp -module_interface std_containers.module_interface std_filesystem.module_interface My questions are: 1. Is this a valid description of how this is expected to work regarding source code layout and content? 2. When compiling a module named x from a set of files I assume a 'module x [[interface]]' statement can only appear in one of those files? 3. But a 'module x [[partition]]' can appear in multiple files. 4. But can a single file contain multiple module id [[interface]] statements and can the same id name appear more than once in that file; i.e. can the user try to define multiple module interfaces or modules from a single file. 5. Same question for module id [[partition]] 6. I tried this with the MS 2017 compiler and I didn't get anywhere but I assume this is because the compiler doesn't implement what is proposed above yet because the Toronto meeting hasn't agreed this yet. Is that correct? 7. The paper suggests attributes for [[partition]] and [[interface]]. Why attributes? Is this to avoid introducing keywords? Users would not really appreciate using attributes here? I assume this is known. Searching for all module X elements by just doing a literal search on "module X" seems appealing though. That's my questions, thanks. GM -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d9edee7-e709-467f-bb9f-9001d5e2a421%40isocpp.org. ------=_Part_3418_664593500.1498741035230 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Everyone

I'm tryin= g to follow the module proposals and the latest suggestions regarding them = from the pre Toronto mailing.

Could somebody please clarify h= ow the latest modules proposal=C2=A0suggests we=C2=A0define a module?
=

Is it like this:

To create and= use a=C2=A0module one needs to have a module=C2=A0interface and it's i= mplementation,

A module interface for a module nam= ed x can be=C2=A0defined by a single file containing a=C2=A0module=C2=A0x [= [interface]] statement;
OR
A module=C2=A0interface=C2=A0can=C2= =A0be defined by=C2=A0a group of files=C2=A0where each file contains=C2=A0a= =C2=A0module=C2=A0x [[partition]] statement';

= In the module definition=C2=A0file, they just announce the source that foll= ows=C2=A0defines the module x by doing simply: module x;

So if someone was going to define the=C2=A0STL via modules, they mig= ht do:

// file: std_containers.vector.h
module st= d_containers [[partition]]
class vector { /* ... */ };


// file: std_containers.string.h
module std_containers [[partition= ]]
class string { /*...*/ }

// file:std_contain= ers.vector.cpp
module std_containers;
vector::vector() { }
<= div>
// file: std_containers.string.cpp
string::string() {= }


// file: std_filesystem.h
module std_filesystem [[interfa= ce]]
class path { /* ... */ };
bool some_helper();


=
// file: std_filesystem.cpp

export path::path() { }
export = bool some_helper();


// Then the user might use some = compiler to compile like so:
$ cc std_containers.cpp std_filesystem.cpp<= /div>

To create=C2=A0these files:
std_containe= rs.module_interface
std_filesystem.module_interface
std= _containers.module_implementation; // could be a dll or so file or lib
std_filesystem.module_implementation; // could be a dll or so file or= lib

Then they=C2=A0might create a user of this=C2= =A0module like so:
module_client.cpp
import std_contain= ers; // now string and vector exist
import std_filesystem; // now= path exists.

// And compile it with some compiler=
cc module_client.cpp -module_interface std_containers.module_int= erface std_filesystem.module_interface

My question= s are:
1. Is this a valid description of how=C2=A0this=C2=A0is ex= pected to work regarding source code layout and content?

2. When compiling=C2=A0a module named x from a set of files=C2=A0I a= ssume=C2=A0a 'module x [[interface]]'=C2=A0statement=C2=A0can only = appear in one of those files?
3.=C2=A0But a =C2=A0'module=C2= =A0x=C2=A0[[partition]]' can appear in multiple files.

4. But can a single file contain multiple module=C2=A0id [[interfa= ce]] statements and can the same id name appear=C2=A0more than once=C2=A0in= that file;
i.e. can the user try to define multiple module inter= faces or modules from a single file.

5. Same quest= ion for module id [[partition]]

6. I tried this wi= th the MS 2017 compiler and I didn't get anywhere but I assume this is = because the compiler doesn't implement=C2=A0what is proposed above yet= =C2=A0because=C2=A0the Toronto meeting hasn't agreed this yet. Is that = correct?

7. The paper suggests attributes for [[pa= rtition]] and [[interface]]. Why attributes?
Is this to avoid int= roducing keywords?=C2=A0Users=C2=A0would not really appreciate using attrib= utes here?
I assume this is known.
Searching for all mo= dule X elements=C2=A0by just doing a literal search on "module X"= seems appealing though.

That's my questions, = thanks.
GM


--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/5d9edee7-e709-467f-bb9f-9001d5e2a421= %40isocpp.org.
------=_Part_3418_664593500.1498741035230-- ------=_Part_3417_724499250.1498741035230-- .