<div dir="ltr">FWIW - if you're curious about contributing these things to upstream Clang - the policy on language extensions is documented here: <a href="https://clang.llvm.org/get_involved.html">https://clang.llvm.org/get_involved.html</a> </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 30, 2019 at 4:00 AM via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi folks!<br>
<br>
I think most of you are cool programmers and know several programming languages. Even tough here we're all about C++, most knows something like Python, Java, C# or whatever.<br>
<br>
I love the performance you can get by means of C++. But I also wanted to make it better.<br>
At least following things:<br>
* modularity<br>
* reflection<br>
* set of syntactic sugars.<br>
<br>
Currently I'm working on modularity. Yep, there are several versions of modules TS. But main thing I disagree with modules TS and like is that it introduces one more degree of namespace notion. First degree is a file system, second are C++ namespaces, and it is proposed to have a third degree which is modules namespace. So, when you're developing complex project you should make similar decision three times: where to put file?, in which namespace it should be?, in which module it should be? This is not about discussion, though. It's OK. Everybody can follow his own way. May be some people love this.<br>
<br>
Anyways let's consider another approach. Instead why not to keep single namespace notion all the way? That means coincidence of filesystem path and legacy C++ namespaces. One may say this sort of restriction is too much for C++, for it was always about good flexibility.<br>
I think that may be it reduces a flexibility a bit, but it will simplify packages lookup routine. It will also unload your brains with eternal question "in which directory should I store that thing?" Basically, I follow approach "good laws are limitations of our worst to release our best". And you know, what is the reason of having a tool if it is too liquid to be held in your hands? There should be some border between flexibility and liquidity after all.<br>
<br>
So finally we are about meaty part of this post. In first part of C++ improvements I propose next modules concept. Just look at that.<br>
<br>
// File1.cpp<br>
#import com::mylib::MyAnotherClass;<br>
#import com::guyslib::ThirdClass;<br>
package namespace com::mylib {<br>
class MyClass {<br>
MyAnotherClass v;<br>
guyslib::ThirdClass v2;<br>
};<br>
}<br>
<br>
or even this (second option):<br>
<br>
// File1.cpp<br>
package namespace com::mylib {<br>
class MyClass {<br>
global::com::mylib::MyAnotherClass v;<br>
global::com::guyslib::ThirdClass v2;<br>
};<br>
}<br>
<br>
In first case we do manual import. In second option we use "global" keyword and it triggers automatic import mechs. There are no additional degree of namespaces. We *reuse* existing namespace concept with a single new attribute "package".<br>
<br>
"package" attribute tells compiler that current file is a... package! Well, it also tells that it is allowed to define only symbols with same name inside. Anywere else you can treat it just like a regular namespaces.<br>
<br>
Also package namespaces are allowed only for files with particular path which should correspond to namespace path. All this sort of measures makes it really easy to perform fast dependency lookup and resolution.<br>
<br>
Second option with automatic dependencies lookup is implemented already. It is based on clang frontend and "dependent types" mechanics. Well, when I started work on it, that was like a challenge to make it automatic. As it was later discovered, though, it is not always convenient in practise.<br>
<br>
The reason why I started this thread is that perhaps some of you guys kind of on the same wave and perhaps want to participate.<br>
<br>
Below is a link to my open-source clang-based project.<br>
<a href="https://gitlab.com/dyatkovskiy/cppl" rel="noreferrer" target="_blank">https://gitlab.com/dyatkovskiy/cppl</a><br>
<br>
Currently I'm about to implement #import directive (manual dependencies declaration). And if some of you are interested, please feel free to email me, or join the project.<br>
<br>
And thanks for your attention!<br>
<br>
-Stepan<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>