On Friday, 28 July 2017 at 19:20:31 UTC, 12345swordy wrote:
> Reading through the dlang documentation, I can't find a way to enforce a certain code standard using mixins _traits ctfe.
>
> Imo it's very beneficial to have coding standards enforce by compile time.

Typical way to enforce patterns are traits like isInputRange.
You do something like
static assert(isInputRange!MyRange);
and it checks whether the type follows the pattern.
It can't see inside function body though, only member declarations. P0707 works with declarations too, it uses declarative macros to generate code because it doesn't propose to reflect on function body.

On Saturday, 29 July 2017 at 06:22:46 UTC, Nicholas Wilson wrote:
> There is no reason you can't reflect on DblRep and generate the bit fields, see Stevens recent talk. https://forum.dlang.org/thread/ojai9r$se7$1@digitalmars.com

That will be cleaner indeed, but DCD will still be unable to see it, the source struct will be unrelated to actually used generated code.

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?

Thanks for mentioning this: I just watched the video linked from his blog post, but didn't read the paper.

It's an elegant design, but strikes me as a bad idea for the language. This is the seductive kind of architecture produced by architecture astronauts, because it solves real needs, ie interface, value, etc. as "keywords," but generalizes it in such a way that it's very customizable (as opposed to architecture that shuffles codes around and solves no real need).

To start off, this basically will lead to a ton of metaclass "keywords" added to every codebase, which simplifies how much code is written but still requires the programmer to understand how the underlying metaclass works.  It balkanizes the language further, because every codebase will have their own metaclasses, possibly even naming the exact same metaclass implementation differently.  You could work around the syntax problem of a keyword explosion a bit by making coders type "MetaClass::interface" instead of just "interface", but that still leaves the other issues.

The job of language designers like Sutter is to find abstractions that would make programmers' lives easier and bake them into the language.  Sometimes, the way people use these abstractions is so varied that you need what he calls "encapsulated abstractions" or "user-written extensions" like functions, classes, or modules, on one of his last slides with 7 mins. to go.

Other times, there are some really common ways to use the abstraction and you're better off adding the most common customization of that abstraction to the language with a particular keyword, and saying you can't do all those other niche customizations.  That is the job of the language designer, and it is as important what he excludes as much as what he includes.

I think he'd be better off just adding keywords like "interface" for the metaclasses he thinks are really common, rather than allowing programmers to define it any way they want.  However, this is an empirical question: how widely do C++ programmers need to customize their "meta-classes" as they're implemented now, and is it worth the additional keywords that noobs would see sprinkled all over codebases and get confused by?  I don't write C++, so I can't definitely answer this question, but my guess is that it isn't worth it.

If he's right that C++ use is so balkanized, this will simplify some code but further balkanize the language.  That might be worth it for them, but rather than simplifying the language, it makes it more powerful and more complex, heading higher up into the hills rather than the lower ground he claims to be heading for.

On Fri, 2017-07-28 at 20:44 +0200, Jacob Carlborg via Digitalmars-d wrote:
> On 2017-07-28 12:30, Russel Winder via Digitalmars-d wrote:
> 
> > 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.
> 
> Quite unfortunate that the questions did not appear in the video.

Not unfortunate, but I had thought they were recorded. Certainly, all the
questions and answers went through the PA, I had thought they were being
recorded.

-- 
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 7/31/2017 5:41 AM, Joakim wrote:
> If he's right that C++ use is so balkanized, this will simplify some code but further balkanize the language.  That might be worth it for them, but rather than simplifying the language, it makes it more powerful and more complex, heading higher up into the hills rather than the lower ground he claims to be heading for.

I can't say I understand the proposal, but if it is similar to AST macros, my argument against that is well known and similar to yours.

On Tuesday, 1 August 2017 at 22:06:28 UTC, Walter Bright wrote:
> On 7/31/2017 5:41 AM, Joakim wrote:
>> If he's right that C++ use is so balkanized, this will simplify some code but further balkanize the language.  That might be worth it for them, but rather than simplifying the language, it makes it more powerful and more complex, heading higher up into the hills rather than the lower ground he claims to be heading for.
>
> I can't say I understand the proposal, but if it is similar to AST macros, my argument against that is well known and similar to yours.

It's basically a restricted form of AST-Macros.
Not as aweful as it could have been but still quite complex and I have no idea how one would implement that efficiently.

On Tuesday, 1 August 2017 at 22:11:47 UTC, Stefan Koch wrote:
> On Tuesday, 1 August 2017 at 22:06:28 UTC, Walter Bright wrote:
>> On 7/31/2017 5:41 AM, Joakim wrote:
>>> If he's right that C++ use is so balkanized, this will simplify some code but further balkanize the language.  That might be worth it for them, but rather than simplifying the language, it makes it more powerful and more complex, heading higher up into the hills rather than the lower ground he claims to be heading for.
>>
>> I can't say I understand the proposal, but if it is similar to AST macros, my argument against that is well known and similar to yours.
>
> It's basically a restricted form of AST-Macros.
> Not as aweful as it could have been but still quite complex and I have no idea how one would implement that efficiently.

Luckily they don't need to: Since when was C++ compilation ever efficient?

On Tuesday, 1 August 2017 at 22:11:47 UTC, Stefan Koch wrote:
> It's basically a restricted form of AST-Macros.
> Not as aweful as it could have been but still quite complex and I have no idea how one would implement that efficiently.

They look as efficient as templates. Both duplicate the AST tree, don't they?

On Tue, 2017-08-01 at 15:06 -0700, Walter Bright via Digitalmars-d wrote:
> 
[…]
> I can't say I understand the proposal, but if it is similar to AST macros,
> my
> argument against that is well known and similar to yours

And there was me being a great fan of AST macros in those languages that have them.

> .
-- 
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 8/2/2017 2:24 AM, Russel Winder via Digitalmars-d wrote:
> And there was me being a great fan of AST macros in those languages that have
> them.

There are many who share your views here :-)