Re: [OT] Generative C++
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/xxqdnjscsdtbbwkma...@forum.dlang.org
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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"
Re: [OT] Generative C++
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
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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/ikavudrxltlbuceea...@forum.dlang.org
Re: [OT] Generative C++
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?
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
https://www.xkcd.com/1028/ https://www.xkcd.com/1860/
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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?
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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
Re: [OT] Generative C++
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!
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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
Re: [OT] Generative C++
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?
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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++?
Re: [OT] Generative C++
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?
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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
Re: [OT] Generative C++
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
Re: [OT] Generative C++
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 :-)
Re: [OT] Generative C++
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.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: [OT] Generative C++
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?
Re: [OT] Generative C++
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?
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
On 28 July 2017 at 21:20, 12345swordy via Digitalmars-d wrote: > On Friday, 28 July 2017 at 18:24:02 UTC, H. S. Teoh wrote: >> >> On Fri, Jul 28, 2017 at 05:38:10PM +, 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.
Re: [OT] Generative C++
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
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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;
}
}
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
On Friday, 28 July 2017 at 18:24:02 UTC, H. S. Teoh wrote: On Fri, Jul 28, 2017 at 05:38:10PM +, 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.
Re: [OT] Generative C++
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
Re: [OT] Generative C++
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
Re: [OT] Generative C++
On Fri, Jul 28, 2017 at 05:38:10PM +, 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
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
On Fri, Jul 28, 2017 at 07:49:02AM +, 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
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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 ?
Re: [OT] Generative C++
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).
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
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.
Re: [OT] Generative C++
On Fri, 2017-07-28 at 07:49 +, 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.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
