[cfe-dev] C++ Levitation: C++ syntax extensions

[David Blaikie via cfe-dev]

FWIW - if you're curious about contributing these things to upstream Clang
- the policy on language extensions is documented here:
https://clang.llvm.org/get_involved.html

On Mon, Sep 30, 2019 at 4:00 AM via cfe-dev <cfe-dev at lists.llvm.org> wrote:

> Hi folks!
>
> 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.
>
> I love the performance you can get by means of C++. But I also wanted to
> make it better.
> At least following things:
> * modularity
> * reflection
> * set of syntactic sugars.
>
> 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.
>
> 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.
> 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.
>
> 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.
>
> // File1.cpp
> #import com::mylib::MyAnotherClass;
> #import com::guyslib::ThirdClass;
> package namespace com::mylib {
>   class MyClass {
>     MyAnotherClass v;
>     guyslib::ThirdClass v2;
>   };
> }
>
> or even this (second option):
>
> // File1.cpp
> package namespace com::mylib {
>   class MyClass {
>     global::com::mylib::MyAnotherClass v;
>     global::com::guyslib::ThirdClass v2;
>   };
> }
>
> 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".
>
> "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.
>
> 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.
>
> 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.
>
> 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.
>
> Below is a link to my open-source clang-based project.
> https://gitlab.com/dyatkovskiy/cppl
>
> 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.
>
> And thanks for your attention!
>
> -Stepan
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190930/60f51c33/attachment.html>