www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] Generative C++

reply Yuxuan Shui <yshuiv7 gmail.com> writes:
Someone made an interesting proposal to C++: 
https://herbsutter.files.wordpress.com/2017/07/p0707r1.pdf

Thoughts?
Jul 28 2017
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 2017-07-28 at 07:49 +0000, Yuxuan Shui via Digitalmars-d wrote:

 Someone made an interesting proposal to C++:=C2=A0
 https://herbsutter.files.wordpress.com/2017/07/p0707r1.pdf
=20
 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-thought=
s-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 h=
as
got the C++ hardcore folk more excited about the future of C++ that any oth=
er
feature from what I can see. If the proposal makes it into C++20, it will b=
e
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 so=
rt
of usable.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Jul 28 2017
parent reply Jacob Carlborg <doob me.com> writes:
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.

-- 
/Jacob Carlborg
Jul 28 2017
parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
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:
=20

 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.


=20
 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.
=20
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Aug 01 2017
prev sibling next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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.
Jul 28 2017
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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.
Jul 28 2017
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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.
Jul 28 2017
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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.
Jul 28 2017
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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).
Jul 28 2017
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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 ?
Jul 28 2017
parent 12345swordy <alexanderheistermann gmail.com> writes:
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.
Jul 28 2017
prev sibling parent reply Kagamin <spam here.lot> writes:
On Friday, 28 July 2017 at 15:41:28 UTC, 12345swordy wrote:

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


struct DblRep
{
   mixin(bitfieldString([
     BitFieldDesc(Type.Ulong, "fraction", 23),
     BitFieldDesc(Type.Ushort, "exponent", 8),
     BitFieldDesc(Type.Bool, "sign", 1)
   ]));
}

With macros would look like

struct DblRep
{
    BitFields
   struct
   {
      23 ulong fraction;
      8 ushort exponent;
      1 bool sign;
   }
}
Jul 28 2017
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 28 July 2017 at 22:12:32 UTC, Kagamin wrote:

 On Friday, 28 July 2017 at 15:41:28 UTC, 12345swordy wrote:

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


 struct DblRep
 {
   mixin(bitfieldString([
     BitFieldDesc(Type.Ulong, "fraction", 23),
     BitFieldDesc(Type.Ushort, "exponent", 8),
     BitFieldDesc(Type.Bool, "sign", 1)
   ]));
 }

 With macros would look like

 struct DblRep
 {
    BitFields
   struct
   {
      23 ulong fraction;
      8 ushort exponent;
      1 bool sign;
   }
 }


The great thing about string-mixins is that you can explain 
easily and they have an understandable representation which you 
can dump out easily.

Whereas with AST macros you need to understand the macro and can 
not as easily dump the output.
Jul 28 2017
prev sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Friday, 28 July 2017 at 22:12:32 UTC, Kagamin wrote:

 On Friday, 28 July 2017 at 15:41:28 UTC, 12345swordy wrote:

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


 struct DblRep
 {
   mixin(bitfieldString([
     BitFieldDesc(Type.Ulong, "fraction", 23),
     BitFieldDesc(Type.Ushort, "exponent", 8),
     BitFieldDesc(Type.Bool, "sign", 1)
   ]));
 }

 With macros would look like

 struct DblRep
 {
    BitFields
   struct
   {
      23 ulong fraction;
      8 ushort exponent;
      1 bool sign;
   }
 }


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
Jul 28 2017
parent Kagamin <spam here.lot> writes:
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.
Jul 29 2017
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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
Jul 28 2017
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 28 July 2017 at 17:18:35 UTC, H. S. Teoh wrote:

 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.


One significant problem with this is that, you loose alot of 
static introspection and reasoning capabilities.

As you need not only understand the core concepts of the language 
but also the specific dialect written by user-code.

Also while it may look like a reduction of complexity we compiler 
guys have to me even more on our guard if the users can 
manipulate asts too freely.

And it is very easy to write spaghetti-code which looks totally 
harmless.
We are throwing the programmers intuition away if we go the 
"make-a-lanugauge" road.
Jul 28 2017
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Jul 28, 2017 at 05:38:10PM +0000, Stefan Koch via Digitalmars-d wrote:

 On Friday, 28 July 2017 at 17:18:35 UTC, H. S. Teoh wrote:

 
 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.


 
 One significant problem with this is that, you loose alot of static
 introspection and reasoning capabilities.


Not necessarily.  Perhaps "IR" is the wrong term to use, as in compiler
parlance it means something very close to machine code, but the idea is
that the core language should provide enough semantics that you can
still introspect and reason about it meaningfully.  To use the C++
example, it would provide semantic notions like access permissions, so
that you can still meaninfully introspect whether a method is public,
private, protected, etc..



 As you need not only understand the core concepts of the language but
 also the specific dialect written by user-code.


But this already happens in today's large projects.  Every project has
its own way of doing certain things, and in order to understand what the
code is actually doing, you have to understand what is effectively its
own dialect of the language.  Not following the project's way of doing
things is usually what leads to problems later on -- e.g., the project
may require you always allocate with customMalloc, but as a new person
to the project you write malloc instead, and it blows up because the
rest of the code assumes things that are not true when you don't use
customMalloc.



 Also while it may look like a reduction of complexity we compiler guys
 have to me even more on our guard if the users can manipulate asts too
 freely.


No, this is not about manipulating ASTs. Well at least, if properly
designed, it wouldn't let you perform arbitrary transformations to
arbitrary parts of the AST.  A proper design would have to be such that
any such user-defined behaviours must be properly-contained and
encapsulated so that it won't result in an explosion of complexity that
affects things outside.



 And it is very easy to write spaghetti-code which looks totally
 harmless.


It's already possible to write spaghetti code today. :-D  Looking
totally harmless is just icing on the cake. :-D  As Larry Wall once
said, "Real Programmers can write assembly code in any language. :-)".



 We are throwing the programmers intuition away if we go the
 "make-a-lanugauge" road.


Actually, this is about *keeping* programmer intuition rather than
throwing it away.  Every now and then we get someone popping into the
forum asking why D operator overloading is so constricted compared to
C++, and how to work around that.  Andrei's standard answer is always
"write your own DSL", since CTFE lets you parse your DSL at
compile-time.  I don't think it's fair to say that DSLs are throwing
programmers' intuition away, even though it *is*, essentially, something
along the "make-a-language" road.

So the key thing here is a proper design that encapsulates such DSLs or
user-defined dialects, so that it's clearly contained in its own thing
rather than polluting the global syntax-space. If we wanted the latter,
C macros already allows us to do this (e.g., see any IOCCC entry :-D).
C++ metaclasses are encapsulated because the customization only exists
in the namespace of that metaclass; you can't arbitrarily modify the
semantics of classes outside of that metaclass.  D DSLs are also
encapsulated because they are (possibly compile-time) string arguments
that don't directly interact with "normal" D syntax.  Similarly, a
proper design of a meta-language like what I'm describing should also
ensure that things are properly encapsulated so that code with custom
behaviour is clearly different from code with "default" behaviour, even
if they are at some level symmetric w.r.t. each other.


T

-- 
Never trust an operating system you don't have source for! -- Martin Schulze
Jul 28 2017
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 28 July 2017 at 18:24:02 UTC, H. S. Teoh wrote:

 On Fri, Jul 28, 2017 at 05:38:10PM +0000, Stefan Koch via 
 Digitalmars-d wrote:

 [...]


 Not necessarily.  Perhaps "IR" is the wrong term to use, as in 
 compiler parlance it means something very close to machine 
 code, but the idea is that the core language should provide 
 enough semantics that you can still introspect and reason about 
 it meaningfully.  To use the C++ example, it would provide 
 semantic notions like access permissions, so that you can still 
 meaninfully introspect whether a method is public, private, 
 protected, etc..

 [...]


Reading through the dlang documentation, I can't find a way to 
enforce a certain code standard using mixins _traits ctfe.
For example you have a custom allocator and you forbid using c 
malloc in functions and class constructor, and you create the 
 noMalloc to achieve this. To me that what's currently missing in 
D. To enforce certain code standards in projects to prevent 
developers accidentally using a certain function/class that is 
forbid by the custom attribute and that is not covered by the 
current attributes(safe, nogc, etc).

Imo it's very beneficial to have coding standards enforce by 
compile time.
Jul 28 2017
next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 28 July 2017 at 21:20, 12345swordy via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Friday, 28 July 2017 at 18:24:02 UTC, H. S. Teoh wrote:

 On Fri, Jul 28, 2017 at 05:38:10PM +0000, Stefan Koch via Digitalmars-d
 wrote:

 [...]



 Not necessarily.  Perhaps "IR" is the wrong term to use, as in compiler
 parlance it means something very close to machine code, but the idea is that
 the core language should provide enough semantics that you can still
 introspect and reason about it meaningfully.  To use the C++ example, it
 would provide semantic notions like access permissions, so that you can
 still meaninfully introspect whether a method is public, private, protected,
 etc..

 [...]



 Reading through the dlang documentation, I can't find a way to enforce a
 certain code standard using mixins _traits ctfe.
 For example you have a custom allocator and you forbid using c malloc in
 functions and class constructor, and you create the  noMalloc to achieve
 this. To me that what's currently missing in D. To enforce certain code
 standards in projects to prevent developers accidentally using a certain
 function/class that is forbid by the custom attribute and that is not
 covered by the current attributes(safe, nogc, etc).

 Imo it's very beneficial to have coding standards enforce by compile time.


Sounds an awful lot like how people use UDAs and compile-time
introspection to me.
Jul 29 2017
prev sibling parent Kagamin <spam here.lot> writes:
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.
Jul 29 2017
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-07-28 09:49, Yuxuan Shui wrote:

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


Since no one else has mentioned it yet, I'm going to: it looks 	
suspiciously like AST macros :).

-- 
/Jacob Carlborg
Jul 28 2017
prev sibling next sibling parent Kagamin <spam here.lot> writes:
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?


Looks like a hybrid between imperative and declarative macros. 
It's natural for C++ to add lots of syntax, but declarative 
additions don't look very valuable, because imperative macros are 
already turing-complete and can do any job. With this C++ will 
have 3 macro systems: imperative, declarative and preprocessor.
ps CTFE and AST DOM API naturally make minimalistic and versatile 
AST macros.
Jul 28 2017
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
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.
Jul 31 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 01 2017
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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.
Aug 01 2017
next sibling parent Moritz Maxeiner <moritz ucworks.org> writes:
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?
Aug 01 2017
prev sibling parent Kagamin <spam here.lot> writes:
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?
Aug 02 2017
prev sibling next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2017-08-01 at 15:06 -0700, Walter Bright via Digitalmars-d wrote:

=20


[=E2=80=A6]

 I can't say I understand the proposal, but if it is similar to AST macros=


,

 my=C2=A0
 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 ha=
ve
them.


 .


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Aug 02 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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 :-)
Aug 02 2017
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 2 August 2017 at 09:50:41 UTC, Walter Bright wrote:

 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 :-)


Well d have a goto statement despite having a famous argument 
against goto statments, so it not like d always follows the rules.

Regardless, what impress me the most is the part where it came be 
used to enforce coding standards at compile time. Which I am 
trying to look if it's possible with d and sadly no luck.

Is it to much to ask for d developers to provide a way to enforce 
custom coding standards in a similar fashion that  nogc and  safe 
does?

Alex
Aug 02 2017
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 2 August 2017 at 13:50:49 UTC, 12345swordy wrote:

 Is it to much to ask for d developers to provide a way to 
 enforce custom coding standards in a similar fashion that  nogc 
 and  safe does?

 Alex


Like the ability to run dscanner at compile-time?
https://github.com/dlang-community/D-Scanner
Aug 02 2017
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 2 August 2017 at 14:08:21 UTC, jmh530 wrote:

 On Wednesday, 2 August 2017 at 13:50:49 UTC, 12345swordy wrote:

 Is it to much to ask for d developers to provide a way to 
 enforce custom coding standards in a similar fashion that 
  nogc and  safe does?

 Alex


 Like the ability to run dscanner at compile-time?
 https://github.com/dlang-community/D-Scanner


...No? I was referring to the c++ proposal paper.
Aug 02 2017
parent reply Kagamin <spam here.lot> writes:
On Wednesday, 2 August 2017 at 20:28:38 UTC, 12345swordy wrote:

 ...No? I was referring to the c++ proposal paper.


The paper doesn't propose to enforce coding standards to the 
point you want. D already does what the paper proposes.
Aug 03 2017
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Thursday, 3 August 2017 at 10:43:50 UTC, Kagamin wrote:

 On Wednesday, 2 August 2017 at 20:28:38 UTC, 12345swordy wrote:

 ...No? I was referring to the c++ proposal paper.


 The paper doesn't propose to enforce coding standards to the 
 point you want. D already does what the paper proposes.


Page 2:

"Enable writing
compiler-enforced
patterns for any purpose:
coding standards
(e.g., many
Core Guidelines
“enforce” rules)
"

Yes, it does, right there. Are you reading the same paper that I 
am?
Aug 03 2017
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03.08.2017 20:32, 12345swordy wrote:

 On Thursday, 3 August 2017 at 10:43:50 UTC, Kagamin wrote:

 On Wednesday, 2 August 2017 at 20:28:38 UTC, 12345swordy wrote:

 ...No? I was referring to the c++ proposal paper.


 The paper doesn't propose to enforce coding standards to the point you 
 want. D already does what the paper proposes.


 Page 2:
 
 "Enable writing
 compiler-enforced
 patterns for any purpose:
 coding standards
 (e.g., many
 Core Guidelines
 “enforce” rules)
 "
 
 Yes, it does, right there. Are you reading the same paper that I am?


On 02.08.2017 15:50, 12345swordy wrote:

   > Is it to much to ask for d developers to provide a way to enforce custom
 coding standards in a similar fashion that  nogc and  safe does?


How would you use the proposed features to implement  safe or  nogc 
within C++?
Aug 03 2017
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Thursday, 3 August 2017 at 19:02:17 UTC, Timon Gehr wrote:

 On 03.08.2017 20:32, 12345swordy wrote:

 On Thursday, 3 August 2017 at 10:43:50 UTC, Kagamin wrote:

 On Wednesday, 2 August 2017 at 20:28:38 UTC, 12345swordy 
 wrote:

 ...No? I was referring to the c++ proposal paper.


 The paper doesn't propose to enforce coding standards to the 
 point you want. D already does what the paper proposes.


 Page 2:
 
 "Enable writing
 compiler-enforced
 patterns for any purpose:
 coding standards
 (e.g., many
 Core Guidelines
 “enforce” rules)
 "
 
 Yes, it does, right there. Are you reading the same paper that 
 I am?


 On 02.08.2017 15:50, 12345swordy wrote:

   > Is it to much to ask for d developers to provide a way to 
 enforce custom
 coding standards in a similar fashion that  nogc and  safe 
 does?


 How would you use the proposed features to implement  safe or 
  nogc within C++?


I am not interested in arguing about what I said or I didn't 
said. Regardless what you asking is ridiculous, as 1.) there is 
no gc exist in c++ in the first place 2.)it's still a concept at 
this point of time which may be rejected in the future.
Aug 03 2017
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03.08.2017 21:28, 12345swordy wrote:

 On Thursday, 3 August 2017 at 19:02:17 UTC, Timon Gehr wrote:

 On 03.08.2017 20:32, 12345swordy wrote:

 On Thursday, 3 August 2017 at 10:43:50 UTC, Kagamin wrote:

 On Wednesday, 2 August 2017 at 20:28:38 UTC, 12345swordy wrote:

 ...No? I was referring to the c++ proposal paper.


 The paper doesn't propose to enforce coding standards to the point 
 you want. D already does what the paper proposes.


 Page 2:

 "Enable writing
 compiler-enforced
 patterns for any purpose:
 coding standards
 (e.g., many
 Core Guidelines
 “enforce” rules)
 "

 Yes, it does, right there. Are you reading the same paper that I am?


 On 02.08.2017 15:50, 12345swordy wrote:

   > Is it to much to ask for d developers to provide a way to enforce 
 custom
 coding standards in a similar fashion that  nogc and  safe does?


 How would you use the proposed features to implement  safe or  nogc 
 within C++?


 
 I am not interested in arguing about what I said or I didn't said. 


I don't understand the relevance of this sentence.


 Regardless what you asking is ridiculous, as 1.) there is no gc exist in 
 c++ in the first place


https://en.wikipedia.org/wiki/Boehm_garbage_collector


 2.)it's still a concept at this point of time 
 which may be rejected in the future.


How does that make my question ridiculous?
Aug 03 2017
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Thursday, 3 August 2017 at 19:45:12 UTC, Timon Gehr wrote:

 On 03.08.2017 21:28, 12345swordy wrote:

 On Thursday, 3 August 2017 at 19:02:17 UTC, Timon Gehr wrote:

 On 03.08.2017 20:32, 12345swordy wrote:

 [...]


 On 02.08.2017 15:50, 12345swordy wrote:

 [...]


 How would you use the proposed features to implement  safe or 
  nogc within C++?


 
 I am not interested in arguing about what I said or I didn't 
 said.


 I don't understand the relevance of this sentence.


 Regardless what you asking is ridiculous, as 1.) there is no 
 gc exist in c++ in the first place


 https://en.wikipedia.org/wiki/Boehm_garbage_collector


 2.)it's still a concept at this point of time which may be 
 rejected in the future.


 How does that make my question ridiculous?


You are splinting hairs here. The gc that you linked is a third 
party library, that is not the same as having it built into the 
language itself. Clear difference.

Alex
Aug 03 2017
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03.08.2017 22:06, 12345swordy wrote:

 On Thursday, 3 August 2017 at 19:45:12 UTC, Timon Gehr wrote:

 On 03.08.2017 21:28, 12345swordy wrote:

 On Thursday, 3 August 2017 at 19:02:17 UTC, Timon Gehr wrote:

 On 03.08.2017 20:32, 12345swordy wrote:

 [...]


 On 02.08.2017 15:50, 12345swordy wrote:

 [...]


 How would you use the proposed features to implement  safe or  nogc 
 within C++?


 I am not interested in arguing about what I said or I didn't said.


 I don't understand the relevance of this sentence.


 Regardless what you asking is ridiculous, as 1.) there is no gc exist 
 in c++ in the first place


 https://en.wikipedia.org/wiki/Boehm_garbage_collector


 2.)it's still a concept at this point of time which may be rejected 
 in the future.


 How does that make my question ridiculous?


 You are splinting hairs here.


That's a quite poetic way to describe the futility of my endeavor to 
engage you in a productive discussion. Also see 
http://medical-dictionary.thefreedictionary.com/splinting . [1]


 The gc that you linked is a third party 
 library, that is not the same as having it built into the language 
 itself.


The C++  nogc implementation would also not be built-in, and whether or 
not the memory allocator in question is built-in has no bearing on 
whether my question was ridiculous or not. (I.e. you are splitting hairs.)


 Clear difference.


Clear, yet irrelevant.


BTW: If you are not interested in actually discussing the applicability 
of the proposal to enforcing coding standards to the point you outlined 
( safe and  nogc), we can stop at any time. I was just curious how you 
would achieve this.



[1] Note that here I was deliberately splitting hairs, to demonstrate 
the difference.
Aug 03 2017
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Thursday, 3 August 2017 at 20:56:38 UTC, Timon Gehr wrote:

 On 03.08.2017 22:06, 12345swordy wrote:

 On Thursday, 3 August 2017 at 19:45:12 UTC, Timon Gehr wrote:

 On 03.08.2017 21:28, 12345swordy wrote:

 On Thursday, 3 August 2017 at 19:02:17 UTC, Timon Gehr wrote:

 On 03.08.2017 20:32, 12345swordy wrote:

 [...]


 On 02.08.2017 15:50, 12345swordy wrote:

 [...]


 How would you use the proposed features to implement  safe 
 or  nogc within C++?


 I am not interested in arguing about what I said or I didn't 
 said.


 I don't understand the relevance of this sentence.


 Regardless what you asking is ridiculous, as 1.) there is no 
 gc exist in c++ in the first place


 https://en.wikipedia.org/wiki/Boehm_garbage_collector


 2.)it's still a concept at this point of time which may be 
 rejected in the future.


 How does that make my question ridiculous?


 You are splinting hairs here.


 That's a quite poetic way to describe the futility of my 
 endeavor to engage you in a productive discussion. Also see 
 http://medical-dictionary.thefreedictionary.com/splinting . [1]


Not my problem if you don't like my answer. If you going to 
dispute my usage of the phrase "splinting hairs" by post a link 
to the said phrase and not actually point of the error of it then 
don't be surprised that if I dismiss it.


 The gc that you linked is a third party library, that is not 
 the same as having it built into the language itself.


 The C++  nogc implementation would also not be built-in, and 
 whether or not the memory allocator in question is built-in has 
 no bearing on whether my question was ridiculous or not. (I.e. 
 you are splitting hairs.)


I never said anything about a C++  nogc implementation, that was 
you misreading my post. Which again is ridiculous, as c++ does 
not have gc built in. Apparently you don't understand that.


 Clear difference.


 Clear, yet irrelevant.


Nope very relevant. Otherwise by that logic then c++03 have 
variadic templates by using the boost tuple library.

 BTW: If you are not interested in actually discussing the 
 applicability of the proposal to enforcing coding standards to 
 the point you outlined ( safe and  nogc), we can stop at any 
 time. I was just curious how you would achieve this.


It quite understandable that you misunderstood my post that I had 
wrote.
Aug 03 2017
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04.08.2017 01:26, 12345swordy wrote:


 The C++  nogc implementation would also not be built-in, and whether 
 or not the memory allocator in question is built-in has no bearing on 
 whether my question was ridiculous or not. (I.e. you are splitting 
 hairs.)


 I never said anything about a C++  nogc implementation, that was you 
 misreading my post.


Two parties are required for communication.

It was Kagamin who said:

 The paper doesn't propose to enforce coding standards to the point you want.


This is in reference to your earlier:

 
 Regardless, what impress me the most is the part where it came be used to
enforce coding standards at compile time. Which I am trying to look if it's
possible with d and sadly no luck.
 
 Is it to much to ask for d developers to provide a way to enforce custom
coding standards in a similar fashion that  nogc and  safe does? 


Your answer to Kagamin was basically, "yes it does". You implied that 
you want to be able to enforce custom coding standards similar to  nogc 
and  safe, and then you said that the C++ proposal allows it. My 
question was "why?". It would have been perfectly fine at that point for 
you to clarify that that is not in fact what you meant, so next time 
maybe just do that. :)


 Which again is ridiculous, as c++ does not have gc 
 built in. Apparently you don't understand that.


There is nothing to understand. A GC does not need to be built-in for 
someone to want to control its usage with an attribute.



 Aug 03 2017



  parent reply 12345swordy <alexanderheistermann gmail.com>  writes:


On Friday, 4 August 2017 at 00:49:05 UTC, Timon Gehr wrote:

 This is in reference to your earlier:


And I have said "I am not interested in arguing about what I said 
or I didn't said" which you are literately doing right now. If 
trying to make yourself feel better by deliberating 
misrepresenting my post in order to justify your misunderstanding 
then be my guess. I am not interested having a conversation with 
you as it clear to me that you just doing this just to troll me. 
You not the first person who pull a stun like this and it 
certainly won't be the last.


Alex



 Aug 04 2017



 next sibling parent reply Stefan Koch <uplink.coder googlemail.com>  writes:


On Friday, 4 August 2017 at 12:34:21 UTC, 12345swordy wrote:

 [ ... ]


I can understand that you don't want to be trolled.
Many other people feel the same way.
Therefore I'd ask you to reflect on what it means to be trolling.



 Aug 04 2017



  parent  12345swordy <alexanderheistermann gmail.com>  writes:


On Friday, 4 August 2017 at 12:47:49 UTC, Stefan Koch wrote:

 On Friday, 4 August 2017 at 12:34:21 UTC, 12345swordy wrote:

 [ ... ]


 I can understand that you don't want to be trolled.
 Many other people feel the same way.
 Therefore I'd ask you to reflect on what it means to be 
 trolling.


Why? I decided not to respond to him anymore, as I have stated 
before I am not interested in arguing on whatever I said or not. 
Even more so when this forum doesn't allow editing posts for 
clarification.



 Aug 04 2017



prev sibling  parent  Timon Gehr <timon.gehr gmx.ch>  writes:


https://www.xkcd.com/1028/
https://www.xkcd.com/1860/



 Aug 04 2017



prev sibling  parent reply Joakim <dlang joakim.fea.st>  writes:


On Thursday, 3 August 2017 at 19:02:17 UTC, Timon Gehr wrote:

 On 03.08.2017 20:32, 12345swordy wrote:

 On Thursday, 3 August 2017 at 10:43:50 UTC, Kagamin wrote:

 On Wednesday, 2 August 2017 at 20:28:38 UTC, 12345swordy 
 wrote:

 ...No? I was referring to the c++ proposal paper.


 The paper doesn't propose to enforce coding standards to the 
 point you want. D already does what the paper proposes.


 Page 2:
 
 "Enable writing
 compiler-enforced
 patterns for any purpose:
 coding standards
 (e.g., many
 Core Guidelines
 “enforce” rules)
 "
 
 Yes, it does, right there. Are you reading the same paper that 
 I am?


 On 02.08.2017 15:50, 12345swordy wrote:

   > Is it to much to ask for d developers to provide a way to 
 enforce custom
 coding standards in a similar fashion that  nogc and  safe 
 does?


 How would you use the proposed features to implement  safe or 
  nogc within C++?


I think you misread him.  He wants to enforce custom coding 
standards in D similar to how that proposal would allow, and he's 
comparing it to how D does it with attributes for  safe and 
 nogc, but he's not asking about  safe and  nogc specifically.  
Presumably, he's wondering if he can apply other attributes in D 
that could be used to enforce coding standards similar to the 
ones that C++ proposal enables.



 Aug 03 2017



  parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 03.08.2017 22:54, Joakim wrote:

 On Thursday, 3 August 2017 at 19:02:17 UTC, Timon Gehr wrote:

 On 03.08.2017 20:32, 12345swordy wrote:

 On Thursday, 3 August 2017 at 10:43:50 UTC, Kagamin wrote:

 On Wednesday, 2 August 2017 at 20:28:38 UTC, 12345swordy wrote:

 ...No? I was referring to the c++ proposal paper.


 The paper doesn't propose to enforce coding standards to the point 
 you want. D already does what the paper proposes.


 Page 2:

 "Enable writing
 compiler-enforced
 patterns for any purpose:
 coding standards
 (e.g., many
 Core Guidelines
 “enforce” rules)
 "

 Yes, it does, right there. Are you reading the same paper that I am?


 On 02.08.2017 15:50, 12345swordy wrote:

   > Is it to much to ask for d developers to provide a way to enforce 
 custom
 coding standards in a similar fashion that  nogc and  safe does?


 How would you use the proposed features to implement  safe or  nogc 
 within C++?


 
 I think you misread him.


It's very possible that there has been a misunderstanding, but I think 
then it happened earlier in the thread.


 He wants to enforce custom coding standards in 
 D similar to how that proposal would allow, and he's comparing it to how 
 D does it with attributes for  safe and  nogc, but he's not asking about 
  safe and  nogc specifically.



 Presumably, he's wondering if he can apply 
 other attributes in D that could be used to enforce coding standards 
 similar to the ones that C++ proposal enables.


If this is the case, then the answer is that D has similarly powerful 
compile-time reflection. The C++ proposal additionally has nice syntax 
to invoke the checks and can conveniently rewrite the implementation 
in-place (which is not possible in D in the same way). Another thing the 
C++ proposal has that is not in D is the ability to conveniently 
integrate custom error messages with built-in ones.



 Aug 03 2017



prev sibling  parent reply Kagamin <spam here.lot>  writes:


On Thursday, 3 August 2017 at 18:32:25 UTC, 12345swordy wrote:

 "Enable writing
 compiler-enforced
 patterns for any purpose:
 coding standards
 (e.g., many
 Core Guidelines
 “enforce” rules)
 "

 Yes, it does, right there. Are you reading the same paper that 
 I am?


It works only on declarations, like D.



 Aug 04 2017



  parent reply 12345swordy <alexanderheistermann gmail.com>  writes:


On Friday, 4 August 2017 at 16:07:51 UTC, Kagamin wrote:

 On Thursday, 3 August 2017 at 18:32:25 UTC, 12345swordy wrote:

 "Enable writing
 compiler-enforced
 patterns for any purpose:
 coding standards
 (e.g., many
 Core Guidelines
 “enforce” rules)
 "

 Yes, it does, right there. Are you reading the same paper that 
 I am?


 It works only on declarations, like D.


I know that, what is your point?



 Aug 04 2017



 next sibling parent  Kagamin <spam here.lot>  writes:


On Friday, 4 August 2017 at 16:11:11 UTC, 12345swordy wrote:

 I know that, what is your point?


this: 
https://forum.dlang.org/post/ikavudrxltlbuceeaxkj forum.dlang.org



 Aug 04 2017



prev sibling  parent reply Stefan Koch <uplink.coder googlemail.com>  writes:


On Friday, 4 August 2017 at 16:11:11 UTC, 12345swordy wrote:

 On Friday, 4 August 2017 at 16:07:51 UTC, Kagamin wrote:

 On Thursday, 3 August 2017 at 18:32:25 UTC, 12345swordy wrote:

 "Enable writing
 compiler-enforced
 patterns for any purpose:
 coding standards
 (e.g., many
 Core Guidelines
 “enforce” rules)
 "

 Yes, it does, right there. Are you reading the same paper 
 that I am?


 It works only on declarations, like D.


 I know that, what is your point?


It means it can't be done.
Do do recursive flow-sensitive checks, (like those needed to 
enforce 'pure' or indeed ' nogc'), you'd have to write a 
self-modifying meta-program.
Which you cannot do.



 Aug 04 2017



  parent reply 12345swordy <alexanderheistermann gmail.com>  writes:


On Friday, 4 August 2017 at 16:27:47 UTC, Stefan Koch wrote:

 On Friday, 4 August 2017 at 16:11:11 UTC, 12345swordy wrote:

 On Friday, 4 August 2017 at 16:07:51 UTC, Kagamin wrote:

 On Thursday, 3 August 2017 at 18:32:25 UTC, 12345swordy wrote:

 "Enable writing
 compiler-enforced
 patterns for any purpose:
 coding standards
 (e.g., many
 Core Guidelines
 “enforce” rules)
 "

 Yes, it does, right there. Are you reading the same paper 
 that I am?


 It works only on declarations, like D.


 I know that, what is your point?


 It means it can't be done.
 Do do recursive flow-sensitive checks, (like those needed to 
 enforce 'pure' or indeed ' nogc'), you'd have to write a 
 self-modifying meta-program.
 Which you cannot do.


I wasn't thinking about recursive checking when I was talking 
about enforcing code standards.

Alex



 Aug 04 2017



 next sibling parent  12345swordy <alexanderheistermann gmail.com>  writes:


On Friday, 4 August 2017 at 16:32:27 UTC, 12345swordy wrote:

 On Friday, 4 August 2017 at 16:27:47 UTC, Stefan Koch wrote:

 On Friday, 4 August 2017 at 16:11:11 UTC, 12345swordy wrote:

 On Friday, 4 August 2017 at 16:07:51 UTC, Kagamin wrote:

 On Thursday, 3 August 2017 at 18:32:25 UTC, 12345swordy 
 wrote:

 [...]


 It works only on declarations, like D.


 I know that, what is your point?


 It means it can't be done.
 Do do recursive flow-sensitive checks, (like those needed to 
 enforce 'pure' or indeed ' nogc'), you'd have to write a 
 self-modifying meta-program.
 Which you cannot do.


 I wasn't thinking about recursive checking when I was talking 
 about enforcing code standards.

 Alex


I was thinking along the lines of "this and only this function 
body that you have to check"



 Aug 04 2017



prev sibling  parent reply Stefan Koch <uplink.coder googlemail.com>  writes:


On Friday, 4 August 2017 at 16:32:27 UTC, 12345swordy wrote:

 On Friday, 4 August 2017 at 16:27:47 UTC, Stefan Koch wrote:

 On Friday, 4 August 2017 at 16:11:11 UTC, 12345swordy wrote:

 On Friday, 4 August 2017 at 16:07:51 UTC, Kagamin wrote:

 On Thursday, 3 August 2017 at 18:32:25 UTC, 12345swordy 
 wrote:

 "Enable writing
 compiler-enforced
 patterns for any purpose:
 coding standards
 (e.g., many
 Core Guidelines
 “enforce” rules)
 "

 Yes, it does, right there. Are you reading the same paper 
 that I am?


 It works only on declarations, like D.


 I know that, what is your point?


 It means it can't be done.
 Do do recursive flow-sensitive checks, (like those needed to 
 enforce 'pure' or indeed ' nogc'), you'd have to write a 
 self-modifying meta-program.
 Which you cannot do.


 I wasn't thinking about recursive checking when I was talking 
 about enforcing code standards.

 Alex


enforcing a standard on the top-level only does not really 
enforce anything.
Which is why Timon asked how you'd write the code.
Because you have to try doing it to see that it is indeed not 
possible to the level that is needed for those constructs.



 Aug 04 2017



  parent reply 12345swordy <alexanderheistermann gmail.com>  writes:


On Friday, 4 August 2017 at 16:36:22 UTC, Stefan Koch wrote:

 On Friday, 4 August 2017 at 16:32:27 UTC, 12345swordy wrote:

 On Friday, 4 August 2017 at 16:27:47 UTC, Stefan Koch wrote:

 On Friday, 4 August 2017 at 16:11:11 UTC, 12345swordy wrote:

 On Friday, 4 August 2017 at 16:07:51 UTC, Kagamin wrote:

 [...]


 I know that, what is your point?


 It means it can't be done.
 Do do recursive flow-sensitive checks, (like those needed to 
 enforce 'pure' or indeed ' nogc'), you'd have to write a 
 self-modifying meta-program.
 Which you cannot do.


 I wasn't thinking about recursive checking when I was talking 
 about enforcing code standards.

 Alex


 enforcing a standard on the top-level only does not really 
 enforce anything.


(I really wish this would be a proper fourm, so I can bold things)
Call it a poor mans enforcer if you wish, that the decision that 
I decided to make.



 Aug 04 2017



  parent  Stefan Koch <uplink.coder googlemail.com>  writes:


On Friday, 4 August 2017 at 16:54:44 UTC, 12345swordy wrote:

 On Friday, 4 August 2017 at 16:36:22 UTC, Stefan Koch wrote:

 On Friday, 4 August 2017 at 16:32:27 UTC, 12345swordy wrote:

 On Friday, 4 August 2017 at 16:27:47 UTC, Stefan Koch wrote:

 On Friday, 4 August 2017 at 16:11:11 UTC, 12345swordy wrote:

 On Friday, 4 August 2017 at 16:07:51 UTC, Kagamin wrote:

 [...]


 I know that, what is your point?


 It means it can't be done.
 Do do recursive flow-sensitive checks, (like those needed to 
 enforce 'pure' or indeed ' nogc'), you'd have to write a 
 self-modifying meta-program.
 Which you cannot do.


 I wasn't thinking about recursive checking when I was talking 
 about enforcing code standards.

 Alex


 enforcing a standard on the top-level only does not really 
 enforce anything.


 (I really wish this would be a proper fourm, so I can bold 
 things)
 Call it a poor mans enforcer if you wish, that the decision 
 that I decided to make.


That is not possible in D.
And I doubt it's possible with meta-classes but I might be wrong 
since I have only skimmed the paper.

To answer the question you posted a while back:

 Is it to much to ask for d developers to provide a way to 
 enforce custom
 coding standards in a similar fashion that  nogc and  safe does?


The answer is yes. It's too much to ask of us. Since for the time 
being we lack in quality menpower.

Here is what would be needed to provide that:

1. specify a programatically accessible version of the whole AST.
2. specify a programatically accessible way to transform that AST.
3. Used the transformed ast.

Which is a lot of work it done correctly.
On top of being a feature which is highly prone to dubious uses.
And that clashes with safety guarantees D tries to provide.



 Aug 04 2017



prev sibling  parent reply Yuxuan Shui <yshuiv7 gmail.com>  writes:


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.


Can you give us a pointer to your arguments? Some of us (me) are 
not familiar with them.

Thanks!



 Aug 03 2017



  parent reply Joakim <dlang joakim.fea.st>  writes:


On Thursday, 3 August 2017 at 22:17:57 UTC, Yuxuan Shui 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.


 Can you give us a pointer to your arguments? Some of us (me) 
 are not familiar with them.

 Thanks!


30-page long thread from four years ago, enjoy: :D

http://forum.dlang.org/thread/l5otb1$1dhi$1 digitalmars.com

This post from Walter may summarize his feelings:

http://forum.dlang.org/post/l6co6u$vo$1 digitalmars.com



 Aug 03 2017



  parent reply jmh530 <john.michael.hall gmail.com>  writes:


On Thursday, 3 August 2017 at 22:38:08 UTC, Joakim wrote:

 30-page long thread from four years ago, enjoy: :D

 http://forum.dlang.org/thread/l5otb1$1dhi$1 digitalmars.com

 This post from Walter may summarize his feelings:

 http://forum.dlang.org/post/l6co6u$vo$1 digitalmars.com


Would it be possible to implement  safe/ nogc/pure/nothrow with 
AST macros?



 Aug 03 2017



  parent  Stefan Koch <uplink.coder googlemail.com>  writes:


On Thursday, 3 August 2017 at 23:59:01 UTC, jmh530 wrote:

 On Thursday, 3 August 2017 at 22:38:08 UTC, Joakim wrote:

 30-page long thread from four years ago, enjoy: :D

 http://forum.dlang.org/thread/l5otb1$1dhi$1 digitalmars.com

 This post from Walter may summarize his feelings:

 http://forum.dlang.org/post/l6co6u$vo$1 digitalmars.com


 Would it be possible to implement  safe/ nogc/pure/nothrow with 
 AST macros?


Nope :)

It's doable with good introspection but local ast-node rewriting 
will not help.
Execpt if you can rewrite the macro itself.

But I'd strongly discourage such a solution.



 Aug 03 2017



prev sibling next sibling parent  Mark <smarksc gmail.com>  writes:


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?


Won't this abstraction compete directly with concepts (lite) and 
even with templates? Metaclasses appear to be at least as 
expressive as these two constructs.



 Aug 06 2017



prev sibling  parent  Joakim <dlang joakim.fea.st>  writes:


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?


Sutter gave a longer presentation on his proposal at CppCon, 
which was posted online late last month and is the most-viewed 
talk from the conference after Bjarne's keynote:

https://www.youtube.com/watch?v=4AfRAVcThyA

I enjoyed watching Regehr's talk on undefined behavior, 
particularly since I hit that shift UB issue in D some time back:

https://www.youtube.com/watch?v=v1COuU2vU_w
https://www.youtube.com/watch?v=TPyLrJED0zQ
http://forum.dlang.org/thread/xxqdnjscsdtbbwkmalfp forum.dlang.org



 Oct 21 2017