Message-ID: <boris.20180831104601_at_[hidden]>

Tom Honermann <tom_at_[hidden]> writes:

> import std.core;
> import widgets;
>
> std::vector<widget>
> get_some_widgets() {
>   /* ... */
> }
>
> Now, consider what a tool, such as an editor, an indexer, a formatter, a
> static analyzer, a translation tool such as SWIG, a documentation generator,
> or any other tool that requires a semantic representation of source code,
> will require in order to perform its intended job.  How will such a tool
> parse this code?  Specifically, how will it resolve the module import
> declarations for std.core and widgets such that declarations for std::vector
> and widget are available in order to successfully parse the remainder of the
> code? 


> I believe sharing module artifacts, in any form, will prove to be
> infeasible.

Agree.

> It seems to me
> that withholding standard library module interface unit source code would be
> rather user hostile and I don't expect any implementations to do so;

Agree.

 
> Translating
> module interface unit source code may require different, even conflicting,
> include paths and macro definitions.  Thus, configuration will become more
> challenging.  I think we should strive for a better solution for modules.

Hm.


> 1. A (set of) module description file(s) that specifies:
> 1. A map from a module name to the file name for the module
> interface unit source code.  A default naming convention could
> also be adopted, though we already have two competing
> conventions (.cppm vs .ixx).
> 2. A set of requirements for translating the module interface unit
> source code (for one or more variations or build modes).  This
> includes preprocessor information (include paths, macro
> definitions, macro undefinitions), and, potentially, language
> dialect requirements (specified in a generic form and, perhaps,
> with the ability to customize for specific tools).
> 2. A method of specifying a path to search for module description
> files, similar to existing include paths.

I would argue against any kind of "search paths" approach (whether for
modules or description files themselves). We've used them for includes
and I think it has proven to be brittle (I am talking about the "header
doesn't exist where you expect it to exist but the compiler found you
another one" kind of situtions) and not toolable (where shoudl I generate
this non-existent header?)

>
> Note that such module description files need not be statically written and
> maintained.  They could be generated directly by a build system, or as a
> side effect of compilation.  If generated, tools dependent on them would be
> dependent on a (partial) build having been completed; as is the case today
> for build systems that generate header files.
>
> Clearly, such a specification falls outside the scope of the C++ standard. 
> However, we could provide a specification in the form of a TS that
> implementors can adhere to.
>
> So, what do you think?  Do you agree that there is a problem worth solving
> here?  Is a common specification a feasible solution?  Is standardizing such
> a specification useful and desirable?  What requirements should be placed on
> the design?  If you are a compiler or tool implementor, have you already
> been working on modules support?  If so, what approaches have you been
> considering?  Are they captured above?  What is your preferred solution?
>
> Thank you to Gabriel Dos Reis, Nathan Burgers, Dmitry Kozhevnikov, Manuel
> Klimek, Peter Sommerlad, and Ville Voutilainen for corrections and
> suggestions they provided on preview drafts of this email.  (This thank you
> is in no way intended to reflect their support, or lack thereof, for
> anything suggested in this email).
>
> Tom.

> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling

-- 
Boris Kolpackov, Code Synthesis        http://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++      http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde