220 34716 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: N4681 modules: why multi-file modules and identifier-style import? Date: Mon, 9 Oct 2017 15:47:12 +0200 Lines: 190 Approved: news@gmane.org Message-ID: References: <891cb16d-2148-4d4f-bb87-6e4fc901817e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="089e082653f489d879055b1d6d3b" X-Trace: blaine.gmane.org 1507556839 11362 195.159.176.226 (9 Oct 2017 13:47:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 9 Oct 2017 13:47:19 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD3NR2WQQ4IBBYX35XHAKGQERZ7SXRY@isocpp.org Mon Oct 09 15:47:15 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f199.google.com ([209.85.223.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e1YOi-0001pg-Ck for gclcip-std-proposals@m.gmane.org; Mon, 09 Oct 2017 15:47:08 +0200 Original-Received: by mail-io0-f199.google.com with SMTP id j17sf5866922iod.18 for ; Mon, 09 Oct 2017 06:47:16 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1507556835; cv=pass; d=google.com; s=arc-20160816; b=lgNNryrXxUvv1jgLIVtzYTwLMABVcNbrnQ46v+ygeGqgqtwf+nmELg0jKvUt9qwVUa OsYyG9FBlM1rBc6+3TLMYjbZhIoKsYsERJQsqfj0B1AcvSKQ0RzIXKLire9IUFkiZFMo tdpL6HcLD03RrcV8X06Agpvy4IoszctmSbj94GXk7YxAiVBkBSOSaHU3n2Dhx2p3jOIc wED7ULBz/FdVRW0OgknGaU4X77GVQ6xJcdKi6eoPcjEaF6bZ6oPxXd/IQD3iusjJwbiI c3RX46eKvDYLjy4qsETJmMmhQapyNFzc6wiRZMiUTG0mMt2/x7qNtw7V1bjC6ungeMex qbdw== 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:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=xfAoFujfkjWj7oHDmljsNcHrPmNMV0RQ4fLXWsvpkMw=; b=esUBXTKl4P2ZLIWhwl5sl0Aa7yI+a+VljhdgU0zCHCkn2gH+/XK0e9m/gFjpiQYfn2 pHeEpXmRPJU5tsjH92SrraadxsmZH2Tz3djG6tI7UMAzOWub8Nyr6eRi8km289RO1ivu 8l1kNEljDWLaPeHgVthAN6AIZrN+NCYRloqfFyksIYyENoOlq2rA7LnTs515NYXr3iHO i6BMFhQBVH3uClC8VUAlxuBTGdnymXxH8MrWuYzB8yR+DJL7QmFpzHrPdvG2IaajPD0n /z/xzArok6QnvAG4XuwQW0zM4W2KoYdpNCEgzrMqw9OiFIaHn6s1T54kf9oK1Jxe5+xf /gLg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=P9LPGS2q; 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=NONE 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:in-reply-to:references:from:date:message-id:subject:to :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=xfAoFujfkjWj7oHDmljsNcHrPmNMV0RQ4fLXWsvpkMw=; b=WEV6CizyuGSyCDTovW4jf5YXTZsa9HN4HJx6G3qODaiFycrv6eM0gcPpyOcvjuKmqy GnmyJ6JSPupEA0KjwFXtCgGmJC+br0WCvMFbd4WLSLOIBtWecqPjKmuY5I7F+CTptcjT q5uL5Oa0nRTEw6XjLSZrU/N9HLHY+WWUggrOfuapOFNKFX1mZz53Nc8Cp16qgoX2BGYN 6zC6kI/vuBqOs51xOMoXRU1bqUXJTwkf6tl2RD1MWnp6uJLxBAFoUEcHy6gRyJJs3vAZ LQU34/o2KoMXl9tSyw9IltdwxmnaBM/QVFtl21+54GMmXtiA85MJ1sznW3sckj3KpKXl EwLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to: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=xfAoFujfkjWj7oHDmljsNcHrPmNMV0RQ4fLXWsvpkMw=; b=PLK/iqqlZK8WXRx1E4BiHGY7SlAEX4J30d559rM5ChnFzKZjmHxxrWMCTgosOjqG1I NSaDB2fbeOuRqj+T62jzsdouCCtA5S8KhyG+egSeWHffdWFB0u3vj7lqox2dGcdFXtze s/C9kni16qfjh7CINDGL6dkOmAv1AT1sh+untt/qoAAix2wjsVQnjVPgqUmIBUzzha5w DK2Ta+AjXtpQt+u6IsIGrHwFlAAUcpt2z93d8sLh+97q/VaWM1kF8kjFNqOe8zXQFJj8 KpH6L5zEoaoTl3/phZMdewKY7v3AtAtpKyITvKHFbBwktaqV0eId9RnFyKDBbn7N4oEf ximQ== X-Gm-Message-State: AMCzsaVQe1a50YLZEn0YCHtW2cB2kuLGZcsFkTkDeGz2PVk70Q06FQQB iRSqurGIGb66///Wk9GQcCSVNg== X-Google-Smtp-Source: AOwi7QBa9ujNSdgIKk3dFMDAwZl47zvkbP/J94B38nX3hqOE0lYSzVnENNWiStbGJJnxdoZrWMw/wQ== X-Received: by 10.107.128.15 with SMTP id b15mr5328749iod.92.1507556835467; Mon, 09 Oct 2017 06:47:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.120.201 with SMTP id p192ls137876itc.2.canary-gmail; Mon, 09 Oct 2017 06:47:14 -0700 (PDT) X-Received: by 10.107.11.27 with SMTP id v27mr5218686ioi.179.1507556834122; Mon, 09 Oct 2017 06:47:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1507556834; cv=none; d=google.com; s=arc-20160816; b=szSKIDODxjskmIOHRaA1geZ9oQGXM5vQjVriQwTrCyj+/sqlkqvcXTDxZz+1lQ6KK5 dLFSeFv8i4HhUW8kCcUx+nv3rovYwWIj9F47ig5gpqFJgdffi7dra/ZwZPT1PByLLCxu mgE7Qyb99alRvv9D/o6ro+BZWnVwrGNscoLMwArx4CqNax1+otwxEjMEZM4z7VXbvdSo iQrppctx8mKr7CM6WHN6d7RbwqA+Mod59c7LWURbWlEKSeWKkxdEakfFva/NoO54ZlGp 3kzZFtfZXmC2lSo4CrAnIwumlWhDOto51+RBYwpHe0/nZnVRKvLOqDdWpcO0kpGSi94f tQ/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=Wsdi8AB5eVGuDmo0L09hRaxBWTFadzz+EFo8byUHBzQ=; b=qqZQejEMEIOxx/+DaG8Tq1wF6a/NS7VvxjB+4zi1VTSQF1Isyf5wGkXPEiIdKtvn8m voCXAUDqgyxh2Mqy8wEYL5AkgZqoDQh3d3ldH1k1nHtW6hQM4IhDAR9ba8d1iYzqr0xM xaw62bnnecls2XrlNwDUokioX9+jXAfuuZ1Hr10Yv+w5mvI9eTf5He7HMQzC8BhO6rde k6caIOQb3r3f9n38AMLp0E89eU8PxBx4gS4j1LQXwzRfsMMutJ8NOQy4QNSZ54UpdI1V DO9S1lep0oDO88XaM7efrSJ71HtfzydqDkKr+7/GhljGgfprNrzPY0UNFlmyRoe0fmHc dT4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=P9LPGS2q; 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=NONE 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 b15sor458447ioa.316.2017.10.09.06.47.14 for (Google Transport Security); Mon, 09 Oct 2017 06:47:14 -0700 (PDT) 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 10.107.70.22 with SMTP id t22mr4014423ioa.69.1507556833479; Mon, 09 Oct 2017 06:47:13 -0700 (PDT) Original-Received: by 10.107.47.163 with HTTP; Mon, 9 Oct 2017 06:47:12 -0700 (PDT) In-Reply-To: <891cb16d-2148-4d4f-bb87-6e4fc901817e@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=P9LPGS2q; 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=NONE dis=NONE) header.from=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:34716 Archived-At: --089e082653f489d879055b1d6d3b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think that you might want to send your question in SG2, the Modules study group: https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/modules A. Jo=C3=ABl Lamotte On 25 September 2017 at 10:44, Igor Baidiuk wrote: > Hello, > > I've read Gabriel's proposal on modules. While overall design aim (minima= l > changes) is understandable (like, no implicit namespaces etc.), there's a > few questions which bother me > First, why use some "abstract module name", instead of simply importing b= y > path? > Identifier style: > > - Requires listing all compilation units outside of linkage unit > sources > - Adds yet another entity, not related to physical module hierarchy > - Conflicts IMO with making only certain subset of modules "public" - > there seems to be no good way to tell compiler that some module should= n't > be observable for package users > - Makes imports lookup more difficult, as compiler is forced to > inspect all files and subdirectories of each "include path" to find de= sired > module; if that's not the case, then user is in fact forced to list al= l > module interface files of imported dependency. > > Path style: > > - Allows to deduce all involved compilation units just by examining > imports at the single root module > - More natural, as it follows physical location of modules or their > declarations on filesystem > - Imported dependency interface lookup is no harder than for current > include approach > > By "path style" I mean something like > > import "std/vector" > > > Second, the purpose of interface/implementation module units is also not > very clear, along with multi-file modules. Looks to me more like incomple= te > imitation of header/cpp duality. > > If not touching name lookup and other things, why a simpler approach > wasn't adopted? > Something like > 1. When translation unit contains > import "path/to/module"; > the file "path/to/module", found through normal header lookup rules (mayb= e > with a few extensions) is considered a module > 2. The whole body of imported translation unit is considered a module > 3. All appropriate symbols marked with "export" are considered exported > and visible to module users directly > > -- > 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/891cb16d-2148-4d4f- > bb87-6e4fc901817e%40isocpp.org > > . > --=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/CAOU91OOQGc064C5wAP79f%3DBVGQYUTH_3uvq1C58OKHnxT= GODXA%40mail.gmail.com. --089e082653f489d879055b1d6d3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think that you might want to send your question in SG2, = the Modules study group:=C2=A0

A= .. Jo=C3=ABl Lamotte

On 25 September 2017 at 10:44, Igor Baidiuk <target.san@g= mail.com> wrote:
Hello,

I've read Gabriel's proposal on modules. Whi= le overall design aim (minimal changes) is understandable (like, no implici= t namespaces etc.), there's a few questions which bother me
First, w= hy use some "abstract module name", instead of simply importing b= y path?
Identifier style:
  • Requires listing all compilation un= its outside of linkage unit sources
  • Adds yet another entity, no= t related to physical module hierarchy
  • Conflicts IMO with making on= ly certain subset of modules "public" - there seems to be no good= way to tell compiler that some module shouldn't be observable for pack= age users
  • Makes imports lookup more difficult, as compiler is force= d to inspect all files and subdirectories of each "include path" = to find desired module; if that's not the case, then user is in fact fo= rced to list all module interface files of imported dependency.

    • Path style:

    • Allows to deduce all involved compilation units= just by examining imports at the single root module
    • More natural, = as it follows physical location of modules or their declarations on filesys= tem
    • Imported dependency interface lookup is no harder than for curr= ent include approach

    By "path style" I mean somet= hing like

    import "std/vector"

    Second, the purpose of interface/implementation module units is also not = very clear, along with multi-file modules. Looks to me more like incomplete= imitation of header/cpp duality.

    If not touching name lookup and ot= her things, why a simpler approach wasn't adopted?
    Something like1. When translation unit contains
    import= "path/to/module";
    the file "path/to/module", found through nor= mal header lookup rules (maybe with a few extensions) is considered a modul= e
    2. The whole body of imported translation unit is considered a module<= br>3. All appropriate symbols marked with "export" are considered= exported and visible to module users directly

--
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-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/891c= b16d-2148-4d4f-bb87-6e4fc901817e%40isocpp.org.

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91OOQGc064C= 5wAP79f%3DBVGQYUTH_3uvq1C58OKHnxTGODXA%40mail.gmail.com.
--089e082653f489d879055b1d6d3b-- .