Someone made an interesting proposal to C++: https://herbsutter.files.wordpress.com/2017/07/p0707r1.pdf

Thoughts?

On Fri, 2017-07-28 at 07:49 +0000, Yuxuan Shui via Digitalmars-d wrote:
> Someone made an interesting proposal to C++: https://herbsutter.files.wordpress.com/2017/07/p0707r1.pdf
> 
> Thoughts?

Herb did the closing keynote at ACCU 2017 on this, the video just had the embargo released. See https://herbsutter.com/2017/07/26/metaclasses-thoughts-o n-generative-c/

This was arguably the most talked about keynote in ACCU history. I had to close the questions after 75 minutes, and even then it went on longer. It has got the C++ hardcore folk more excited about the future of C++ that any other feature from what I can see. If the proposal makes it into C++20, it will be the biggest change since C++11 and be bigger. It may regenerate support for C++ in a way that only modules and concepts can get even close to.

On the other hand there is Fortran 08 and 15 which actually make Fortran sort of usable.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Friday, 28 July 2017 at 07:49:02 UTC, Yuxuan Shui wrote:
> Someone made an interesting proposal to C++: https://herbsutter.files.wordpress.com/2017/07/p0707r1.pdf
>
> Thoughts?

Can D achieve this "metaclasses" using templates and mixins? I not familiar of any features that D can use to enforced coding standard. So correct me if I am wrong as I am not a D guru here, I am more familiar with c++ then anything else atm.

On Friday, 28 July 2017 at 14:39:04 UTC, 12345swordy wrote:
> On Friday, 28 July 2017 at 07:49:02 UTC, Yuxuan Shui wrote:
>> Someone made an interesting proposal to C++: https://herbsutter.files.wordpress.com/2017/07/p0707r1.pdf
>>
>> Thoughts?
>
> Can D achieve this "metaclasses" using templates and mixins? I not familiar of any features that D can use to enforced coding standard. So correct me if I am wrong as I am not a D guru here, I am more familiar with c++ then anything else atm.

Yes we can do that with mixins __traits and ctfe.

On Friday, 28 July 2017 at 14:46:46 UTC, Stefan Koch wrote:
> On Friday, 28 July 2017 at 14:39:04 UTC, 12345swordy wrote:
>> On Friday, 28 July 2017 at 07:49:02 UTC, Yuxuan Shui wrote:
>>> Someone made an interesting proposal to C++: https://herbsutter.files.wordpress.com/2017/07/p0707r1.pdf
>>>
>>> Thoughts?
>>
>> Can D achieve this "metaclasses" using templates and mixins? I not familiar of any features that D can use to enforced coding standard. So correct me if I am wrong as I am not a D guru here, I am more familiar with c++ then anything else atm.
>
> Yes we can do that with mixins __traits and ctfe.

Can you provide a simple example of this? Thanks.

On Friday, 28 July 2017 at 15:09:32 UTC, 12345swordy wrote:
> On Friday, 28 July 2017 at 14:46:46 UTC, Stefan Koch wrote:
>> On Friday, 28 July 2017 at 14:39:04 UTC, 12345swordy wrote:
>>> On Friday, 28 July 2017 at 07:49:02 UTC, Yuxuan Shui wrote:
>>>> Someone made an interesting proposal to C++: https://herbsutter.files.wordpress.com/2017/07/p0707r1.pdf
>>>>
>>>> Thoughts?
>>>
>>> Can D achieve this "metaclasses" using templates and mixins? I not familiar of any features that D can use to enforced coding standard. So correct me if I am wrong as I am not a D guru here, I am more familiar with c++ then anything else atm.
>>
>> Yes we can do that with mixins __traits and ctfe.
>
> Can you provide a simple example of this? Thanks.

Sure look at https://gist.github.com/UplinkCoder/b3501425a4fb4992c6cf1c77d6c3638a
Which will inject propery-methods into a struct to build a costum bitfield.

On Friday, 28 July 2017 at 15:12:29 UTC, Stefan Koch wrote:
> On Friday, 28 July 2017 at 15:09:32 UTC, 12345swordy wrote:
>> On Friday, 28 July 2017 at 14:46:46 UTC, Stefan Koch wrote:
>>> On Friday, 28 July 2017 at 14:39:04 UTC, 12345swordy wrote:
>>>> [...]
>>>
>>> Yes we can do that with mixins __traits and ctfe.
>>
>> Can you provide a simple example of this? Thanks.
>
> Sure look at https://gist.github.com/UplinkCoder/b3501425a4fb4992c6cf1c77d6c3638a
> Which will inject propery-methods into a struct to build a costum bitfield.

... That's not what I consider to be "simple" (Hard to read IMO).

On Friday, 28 July 2017 at 15:41:28 UTC, 12345swordy wrote:
> On Friday, 28 July 2017 at 15:12:29 UTC, Stefan Koch wrote:
>> On Friday, 28 July 2017 at 15:09:32 UTC, 12345swordy wrote:
>>> On Friday, 28 July 2017 at 14:46:46 UTC, Stefan Koch wrote:
>>>> On Friday, 28 July 2017 at 14:39:04 UTC, 12345swordy wrote:
>>>>> [...]
>>>>
>>>> Yes we can do that with mixins __traits and ctfe.
>>>
>>> Can you provide a simple example of this? Thanks.
>>
>> Sure look at https://gist.github.com/UplinkCoder/b3501425a4fb4992c6cf1c77d6c3638a
>> Which will inject propery-methods into a struct to build a costum bitfield.
>
> ... That's not what I consider to be "simple" (Hard to read IMO).

Is it simpler using meta-classes ?

On Friday, 28 July 2017 at 16:04:00 UTC, Stefan Koch wrote:
> On Friday, 28 July 2017 at 15:41:28 UTC, 12345swordy wrote:
>> On Friday, 28 July 2017 at 15:12:29 UTC, Stefan Koch wrote:
>>> On Friday, 28 July 2017 at 15:09:32 UTC, 12345swordy wrote:
>>>> On Friday, 28 July 2017 at 14:46:46 UTC, Stefan Koch wrote:
>>>>> On Friday, 28 July 2017 at 14:39:04 UTC, 12345swordy wrote:
>>>>>> [...]
>>>>>
>>>>> Yes we can do that with mixins __traits and ctfe.
>>>>
>>>> Can you provide a simple example of this? Thanks.
>>>
>>> Sure look at https://gist.github.com/UplinkCoder/b3501425a4fb4992c6cf1c77d6c3638a
>>> Which will inject propery-methods into a struct to build a costum bitfield.
>>
>> ... That's not what I consider to be "simple" (Hard to read IMO).
>
> Is it simpler using meta-classes ?

I don't know, it still a proposal in this stage. Though looking through the d documentation I don't see any _traits that returns the the body of function/struct/class in string format for the std regex to parse.

On Fri, Jul 28, 2017 at 07:49:02AM +0000, Yuxuan Shui via Digitalmars-d wrote:
> Someone made an interesting proposal to C++: https://herbsutter.files.wordpress.com/2017/07/p0707r1.pdf
> 
> Thoughts?

This is very interesting, both as a subject in and of itself, and also in terms of the enthusiastic response it's receiving.

It goes along the same lines of thought I've had for a while now, starting from Andrei's observations way back when in TDPL, that programmers tend to dislike special cases and "magical" behaviour, i.e., special behaviour enjoyed by native types that cannot be emulated by user-defined types.  IOW, we programmers want to be able to "get under the hood" when we need to, and not be locked out by the black box of the language implementation. Black boxes are nice and good when they work, but as we're beginning to realize, no black box is completely satisfactory all the time -- there will always be times when you need to get under the hood.  And it's very frustrating when you're not allowed to, even when it's clear that a tiny tweak to the way things are done would greatly improve your code.

At a deeper level, what we're fundamentally looking for is symmetry -- and I mean that in the mathematical sense of "unchanged under some operation X" (or some set of such operations).  In this particular case, we're looking for symmetry between the language implementation -- default behaviour of built-in types -- and user power -- the ability to change this default behaviour, as exemplified by Meyer's diagram where you're given the ability to modify how the compiler transforms to the source code to the "effective" source code.

This can also be viewed as symmetry between built-in types and user-defined types: it should be possible to write a user-defined type that behaves as though it were a built-in type (the symmetry operation here is commuting baked-in behaviour with user-defined behaviour, or one may say, symmetry between the ability of the language authors and the language users: if the language authors can make the language behave a certain way, the user ought to be able to do the same).

Another instance of symmetry can be found in the principles Meyer set forth at the beginning of his paper: no special syntax should be required for metaclasses; you should be able to employ normal class definition syntax.  IOW, syntax should be symmetric under the operation that exchanges "metaclass definition" with "normal class definition".

An example of *asymmetry* is in C++ template syntax, where the foreign <> syntax is asymmetric w.r.t. non-template syntax (esp. because it clashes with normal uses of the symbols '<' and '>'), and as a result causes readability issues and parsing difficulties.  D template syntax is closer to "normal" syntax, and the higher degree of symmetry makes it easier to use, easier to parse, and have less pathological corner cases.

Metaclasses are only the first step, however.

If we were to take symmetry between baked-in behaviour with user-defined behaviour to the logical conclusion, we would have a language where, at least in theory, *every* language behaviour can be specified in the language itself. I.e., in some sense, the language becomes its own meta-language.

Or, to put that in more concrete terms, the language is formed of two parts: a standardized IR (that forms part of the language spec), and a set of default, higher-level abstractions that the user usually employs as-is, but with the ability to specify new behaviour in terms of the IR and have it available at the higher-level of abstraction.  You could think of the IR as the "core" language that higher-level constructs are lowered to (D already does some of this, to a small extent).  You'd usually use the higher-level constructs, but the IR is directly available to the user, and is standardized so that it works with every language implementation.

Coming back to the topic of metaclasses, the IR would let you specify things like the default access permissions of a class, the default methods, and so on.  The high-level default simply specifies "private" as the default access permission, and implicit ctors, copy ctors, etc., as the default methods.  But since the IR is directly available to the user, he can easily define his own kind of types, maybe call them publicSerializableClass's, where the default permission is "public" and the default methods include a serialize() method.

But having a standardized IR that's available at the language level gives you much, much, more possibilities than merely metaclasses.  You would be able to define foreach loops for ranges without baked-in compiler support, for example. And foreach loops for other kinds of aggregates, and you wouldn't even need opApply.


T

-- 
Life is complex. It consists of real and imaginary parts. -- YHL