First of all, I'm really glad that modules are being proposed to the
Committee, as I feel they're sorely needed. In my opinion eliminating
the need to recompile over and over the same headers due to how the
preprocessor works would be reason enough to accept such a proposal
[1].

Furthermore, modules have proved to be useful in languages that support
them and lastly, just consider how popular the Singleton pattern is and
how modules would be a perfect implementation...

I must say that in general I like Daveed Vandevoorde's proposal and
even for the parts I like the least I Can't say I'd be able to come up
with better alternatives.

I do have one suggestion, though, concerning paragraph 4.1, Startup and
shutdown function (which, by the way, I hope will be included in the
final proposal). Why not reuse the normal constructor/destructor
notation? The example on page 10 would become:

// File_1.cpp:
export Lib {
import std;
Lib() { std::cout << "Hello "; }
~Lib() { std::cout << "World\n"; }
}

No constructor/destructor can be specified without qualification in the
module definition header's scope and the lack of return value makes it
possible to distinguish a module initialization function from a plain
parameterless function declared in the same scope.

On second thoughts it might even be better to forbid such an overload,
to be consistent with how classes work.

Cheers,
Nicola Musatti

[1] Precompiled headers are a clumsy workaround at best. Just consider
the number of artificial dependencies among headers they introduce.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Nicola Musatti wrote:
[...]
> I do have one suggestion, though, concerning paragraph 4.1, Startup and
> shutdown function (which, by the way, I hope will be included in the
> final proposal). Why not reuse the normal constructor/destructor
> notation?

The fact that it's not mentioned in the paper at all is an oversight:
I did consider the syntax, but it's not my favorite.  Part of the issue
is that it visually clashes with my proposal for plugins (run-time
loadable modules).

However, I do think that it's a reasonable and intuitive alternative
and I meant to have is at least mentioned in the paper.  I'll try to
remember adding it in a next revision.

That said, when I presented that particular feature to the evolution
working group, it was received rather coolly.  So I don't plan to fight
hard for it.

Thanks for the feedback!

        Daveed

> The example on page 10 would become:
>
> // File_1.cpp:
> export Lib {
> import std;
> Lib() { std::cout << "Hello "; }
> ~Lib() { std::cout << "World\n"; }
> }
>
> No constructor/destructor can be specified without qualification in the
> module definition header's scope and the lack of return value makes it
> possible to distinguish a module initialization function from a plain
> parameterless function declared in the same scope.
>
> On second thoughts it might even be better to forbid such an overload,
> to be consistent with how classes work.
>
> Cheers,
> Nicola Musatti
>
> [1] Precompiled headers are a clumsy workaround at best. Just consider
> the number of artificial dependencies among headers they introduce.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]