Re: [OT] Modules dropped out of C++17
On 2015-06-11 14:33, Steven Schveighoffer wrote: OK, I see the problem. When you type 'a.' then if you put up the list of members and UFCS functions available, then that list may be huge (and possibly filled with useless calls). That definitely is an issue. However, I think DCD should still support that option. A UI for an ide could be: 1. Lookup members, add to the list a UFCS... button at the bottom. 2. When user clicks on that button, re-query DCD for all functions that take the object as the first parameter, then fill in that list. 3. If user continues to type in a UFCS method, and that doesn't match any members, the autocomplete should start looking for functions that start with that text. The context of where the user is typing can also help to narrow the result, i.e. int a = b.fo Here it could filter out anything that doesn't return something that is convertible to an int. Or at least sort those to the bottom of the list. -- /Jacob Carlborg
Re: [OT] Modules dropped out of C++17
On Thursday, 11 June 2015 at 12:33:55 UTC, Steven Schveighoffer wrote: On 6/10/15 8:52 AM, John Colvin wrote: On Tuesday, 9 June 2015 at 17:43:18 UTC, Steven Schveighoffer wrote: On 6/9/15 4:06 AM, Brian Schott wrote: On Tuesday, 9 June 2015 at 07:49:24 UTC, Shachar Shemesh wrote: Also, you say 5 seconds as if that's a short amount of time. If it takes an automatic scanner 5 seconds, it means the amount of coverage it needs to perform is huge. If anybody was wondering why DCD doesn't support UFCS, this is the answer. I can't find a way to make it fast, useful, or compact in terms of memory use. I can't see how a UFCS lookup is any slower than a normal function lookup. It's just a rewrite. i.e.: a.foo 1. try finding member foo on type a. 2. try finding function foo a. If found, find overload that will take a. What happens as you type: foo(a ??? how is it any different? One problem is that any auto-complete list becomes completely unmanageable. OK, I see the problem. When you type 'a.' then if you put up the list of members and UFCS functions available, then that list may be huge (and possibly filled with useless calls). That definitely is an issue. However, I think DCD should still support that option. A UI for an ide could be: 1. Lookup members, add to the list a UFCS... button at the bottom. 2. When user clicks on that button, re-query DCD for all functions that take the object as the first parameter, then fill in that list. 3. If user continues to type in a UFCS method, and that doesn't match any members, the autocomplete should start looking for functions that start with that text. It would be a shame if DCD doesn't show you functions like arr.empty. However, does DCD support querying a function's parameters when it's a UFCS function? That should at least be manageable. -Steve The funny thing is, one of selling points of C++'s version of UFCS is making it easier for the tools to give useful hints. Personally, I find UFCS and ranges to be the most enticing features of D, allowing me to think of the flow of the data, instead of wondering where the hell does the ) go. Better templates, true immutables, mixins (though ugly), ctfe static if are also appreciated. Modules? Sure, nice to have, but they don't make the top 5 list for me. Why? Call it the Stockholm Syndrome, but most C++ users simply got used to header incurred problems and know to use PIMPL and avoid changing core headers. Though maybe my projects aren't sufficiently large.
Re: [OT] Modules dropped out of C++17
On 6/10/15 8:52 AM, John Colvin wrote: On Tuesday, 9 June 2015 at 17:43:18 UTC, Steven Schveighoffer wrote: On 6/9/15 4:06 AM, Brian Schott wrote: On Tuesday, 9 June 2015 at 07:49:24 UTC, Shachar Shemesh wrote: Also, you say 5 seconds as if that's a short amount of time. If it takes an automatic scanner 5 seconds, it means the amount of coverage it needs to perform is huge. If anybody was wondering why DCD doesn't support UFCS, this is the answer. I can't find a way to make it fast, useful, or compact in terms of memory use. I can't see how a UFCS lookup is any slower than a normal function lookup. It's just a rewrite. i.e.: a.foo 1. try finding member foo on type a. 2. try finding function foo a. If found, find overload that will take a. What happens as you type: foo(a ??? how is it any different? One problem is that any auto-complete list becomes completely unmanageable. OK, I see the problem. When you type 'a.' then if you put up the list of members and UFCS functions available, then that list may be huge (and possibly filled with useless calls). That definitely is an issue. However, I think DCD should still support that option. A UI for an ide could be: 1. Lookup members, add to the list a UFCS... button at the bottom. 2. When user clicks on that button, re-query DCD for all functions that take the object as the first parameter, then fill in that list. 3. If user continues to type in a UFCS method, and that doesn't match any members, the autocomplete should start looking for functions that start with that text. It would be a shame if DCD doesn't show you functions like arr.empty. However, does DCD support querying a function's parameters when it's a UFCS function? That should at least be manageable. -Steve
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 16:01:34 UTC, Andrei Alexandrescu wrote: Same as with @safe @nogc @nothrow @pure. No, these are attributes that change the function's type; constexpr does not. AIU, it still does something along those lines. If you don't have ctfeability expressed in function's contract, you have no idea how you can modify the function's implementation so that to not break other people's code. Sorry for making c++ look cute again :) I guess you could do a lot worse than using a unittest to make sure a function is CTFEable. Isn't it Speculatively mark everything in sight as ctfe?
Re: [OT] Modules dropped out of C++17
On 2015-06-10 01:02, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: I could, but D would not check it? It could most likely be implemented with AST macros. -- /Jacob Carlborg
Re: [OT] Modules dropped out of C++17
On 10/06/15 11:31, Kagamin wrote: Huh? If you have type's method diskIdx and a local variable diskIdx, and they are confusing, what it has to do with UFCS? auto diskIdx = data.diskIdx();
Re: [OT] Modules dropped out of C++17
On Wednesday, 10 June 2015 at 08:53:40 UTC, Shachar Shemesh wrote: On 10/06/15 11:31, Kagamin wrote: Huh? If you have type's method diskIdx and a local variable diskIdx, and they are confusing, what it has to do with UFCS? auto diskIdx = data.diskIdx(); auto diskIdx1 = this.diskIdx; diskIdx1 = f(diskIdx1); return diskIdx;
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 17:43:18 UTC, Steven Schveighoffer wrote: On 6/9/15 4:06 AM, Brian Schott wrote: On Tuesday, 9 June 2015 at 07:49:24 UTC, Shachar Shemesh wrote: Also, you say 5 seconds as if that's a short amount of time. If it takes an automatic scanner 5 seconds, it means the amount of coverage it needs to perform is huge. If anybody was wondering why DCD doesn't support UFCS, this is the answer. I can't find a way to make it fast, useful, or compact in terms of memory use. I can't see how a UFCS lookup is any slower than a normal function lookup. It's just a rewrite. i.e.: a.foo 1. try finding member foo on type a. 2. try finding function foo a. If found, find overload that will take a. What happens as you type: foo(a ??? how is it any different? -Steve One problem is that any auto-complete list becomes completely unmanageable.
Re: [OT] Modules dropped out of C++17
On Wednesday, 10 June 2015 at 06:34:13 UTC, Shachar Shemesh wrote: On 10/06/15 09:14, deadalnix wrote: I do think you think at it the wrong way. people are not telling you it is bad code. You are telling us it is bad code (because you mention having problem that people using other style do not have). It is not a problem in C++. It is not a problem with no UFCS. If the D attitude is if your style doesn't work with D, then it is wrong, then D has already lost. Huh? If you have type's method diskIdx and a local variable diskIdx, and they are confusing, what it has to do with UFCS?
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 23:11:35 UTC, Timon Gehr wrote: enum ct(alias a)=a; Thanks! I need to remember that enum means compile-time constant and not strictly enumeration. I guess one can use __ctfe to use a function at compile time and a lut a runtime too, e.g. __ctfe ? sin(x) : lut_sin[x]
Re: [OT] Modules dropped out of C++17
On Wednesday, 10 June 2015 at 13:43:45 UTC, Shachar Shemesh wrote: On 10/06/15 15:37, Kagamin wrote: On Wednesday, 10 June 2015 at 08:53:40 UTC, Shachar Shemesh wrote: On 10/06/15 11:31, Kagamin wrote: Huh? If you have type's method diskIdx and a local variable diskIdx, and they are confusing, what it has to do with UFCS? auto diskIdx = data.diskIdx(); auto diskIdx1 = this.diskIdx; diskIdx1 = f(diskIdx1); return diskIdx; Was this meant to prove that you can make it confusing? It was your requirement that variables and methods must be similar. What does diskIdx1 mean? Same as in your example, a variable, which receives the disk index. What does f do? Processes the disk index and returns another index according to its logic. Is this.diskIdx a member or a function? A property, which extracts the disk index as you described the function. where did the diskIdx you returned came from? It's defined as a member of the type.
Re: [OT] Modules dropped out of C++17
On 10/06/15 17:05, Kagamin wrote: On Wednesday, 10 June 2015 at 13:43:45 UTC, Shachar Shemesh wrote: On 10/06/15 15:37, Kagamin wrote: On Wednesday, 10 June 2015 at 08:53:40 UTC, Shachar Shemesh wrote: On 10/06/15 11:31, Kagamin wrote: Huh? If you have type's method diskIdx and a local variable diskIdx, and they are confusing, what it has to do with UFCS? auto diskIdx = data.diskIdx(); auto diskIdx1 = this.diskIdx; diskIdx1 = f(diskIdx1); return diskIdx; Was this meant to prove that you can make it confusing? It was your requirement that variables and methods must be similar. I made no such requirement. I just said it sometimes makes sense. You have not answered my most important question: what was it that you were trying to make? Shachar
Re: [OT] Modules dropped out of C++17
On 10/06/15 15:37, Kagamin wrote: On Wednesday, 10 June 2015 at 08:53:40 UTC, Shachar Shemesh wrote: On 10/06/15 11:31, Kagamin wrote: Huh? If you have type's method diskIdx and a local variable diskIdx, and they are confusing, what it has to do with UFCS? auto diskIdx = data.diskIdx(); auto diskIdx1 = this.diskIdx; diskIdx1 = f(diskIdx1); return diskIdx; Was this meant to prove that you can make it confusing? I have no idea what you were trying to convey here. Please explain the point you're trying to make. What does diskIdx1 mean? What does f do? Is this.diskIdx a member or a function? where did the diskIdx you returned came from? Shachar
Re: [OT] Modules dropped out of C++17
On Wednesday, 10 June 2015 at 05:31:18 UTC, Shachar Shemesh wrote: On 10/06/15 00:29, Walter Bright wrote: First off, D does not allow shadowing local variable declarations. Secondly, if you've got a lot of global variables, you've got a program design problem anyway. And lastly, naming everything diskIdx is a problem of your own creation. The first one is called so because it names the index of the disk within a RAID stripe. It's probably an iterator. How would you call the second time I use such an iterator? You might argue that the function that extracts the disk index should be named something more verbose (i.e. - extractTheDiskIndex), but then you are just repeating Ola's criticism[1] of D as if it is a desirable thing. People on this list hold a certain paradigm in their head when they make design decisions. That's fine, except if you hold on to this paradigm and assume anything that violates it is bad code, you are going to end up with Go: a language only fit for those problems that happen to fall within that paradigm. People have preconceptions on how code should look like. I would humbly like to ask people to stop -assuming- that anything that violates them is bad code. Shachar 1 - http://forum.dlang.org/post/uvajlhfztejvwnubs...@forum.dlang.org I do think you think at it the wrong way. people are not telling you it is bad code. You are telling us it is bad code (because you mention having problem that people using other style do not have).
Re: [OT] Modules dropped out of C++17
On 10/06/15 09:14, deadalnix wrote: I do think you think at it the wrong way. people are not telling you it is bad code. You are telling us it is bad code (because you mention having problem that people using other style do not have). It is not a problem in C++. It is not a problem with no UFCS. If the D attitude is if your style doesn't work with D, then it is wrong, then D has already lost. Shachar
Re: [OT] Modules dropped out of C++17
On Wednesday, 10 June 2015 at 01:28:40 UTC, Walter Bright wrote: I'm bemused by the argument that D is deficient because it doesn't implement a non-existent feature of C++. I think you are offended ;^]. I have not said that D is deficient regarding constexpr, I've suggested that I think D is moving more in a high level direction than C++. Which is neither good or bad, just different. constexpr has advantages and disadvantages. But C++ constexpr was originally restricted to expression-like functions. Loops were added later (making it easier to init arrays) AFAIK. My primary use case for constexpr in C++ is: 1. Initializing global constant arrays. These functions I label ct_make_lut_sin(size) etc and only use them for that purpose. 2. Signifiying that a standard class member-function is returning a constant value in a particular version of the class where you expect a varying value, e.g. size(). I only add constexpr when I have to and only use constexpr functions that are O(N) and only where beneficial. It's more like Do I _have_ to make this constexpr?, not Oh yes, I can make this constexpr!. However, D's primary advantage over C++ is that D is easier to get into. No sane person would want to learn C++ from scratch (if they have other options). C++XX is more for people that already know it or have to learn it (for work). D's position will benefit from becoming simpler and more streamlined, not more complex, so constexpr is not the right thing for D, IMO. (Rust and C++ have complexity as a barrier-to-entry) some of these posts. I'm hoping to entice you to contribute in the substantial way that I know you can. I think prodding people to view things differently is substantial, besides it helps me figure out what I want from a language ;-). But I suppose you mean code, I am thinking about doing comparative synthetic benchmarks between idiomatic/readable C++, Rust and D vs not-so-readable hardware oriented C. I think you will find that more people will chime in when the compiler has completed the transition to D and the codebase has been refactored. It doesn't make much sense to get into the C++ codebase at this point where you are transitioning.
Re: [OT] Modules dropped out of C++17
On 6/10/15 8:48 AM, Joakim wrote: On Wednesday, 10 June 2015 at 15:12:47 UTC, ZombineDev wrote: On Monday, 8 June 2015 at 18:17:13 UTC, Paulo Pinto wrote: Apparently modules have been pushed into a Technical Specification, and won't be ready on time for inclusion into ANSI C++ 17. https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/ So, here is another feature that D wins over C++. -- Paulo Sorry, I couldn't resist to share this: https://www.youtube.com/watch?v=ND-TuW0KIgg Lol, that was hilarious. :D Saw a few of those, this is far and away the best one. I guess for a German speaker it would be all like, meh. -- Andrei
Re: [OT] Modules dropped out of C++17
On 06/10/2015 11:12 AM, ZombineDev wrote: Sorry, I couldn't resist to share this: https://www.youtube.com/watch?v=ND-TuW0KIgg Omg that's hilarious :)
Re: [OT] Modules dropped out of C++17
On Wednesday, 10 June 2015 at 15:12:47 UTC, ZombineDev wrote: On Monday, 8 June 2015 at 18:17:13 UTC, Paulo Pinto wrote: Apparently modules have been pushed into a Technical Specification, and won't be ready on time for inclusion into ANSI C++ 17. https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/ So, here is another feature that D wins over C++. -- Paulo Sorry, I couldn't resist to share this: https://www.youtube.com/watch?v=ND-TuW0KIgg Lol, that was hilarious. :D
Re: [OT] Modules dropped out of C++17
On Monday, 8 June 2015 at 18:17:13 UTC, Paulo Pinto wrote: Apparently modules have been pushed into a Technical Specification, and won't be ready on time for inclusion into ANSI C++ 17. https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/ So, here is another feature that D wins over C++. -- Paulo Sorry, I couldn't resist to share this: https://www.youtube.com/watch?v=ND-TuW0KIgg
Re: [OT] Modules dropped out of C++17
On 2015-06-09 11:33, Walter Bright wrote: D's anti-hijacking lookup rules pretty much blunt this sort of problem. Even though the compiler makes sure there's no ambiguity it might not always be so easy to find the definition. -- /Jacob Carlborg
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 08:58:19 UTC, Shachar Shemesh wrote: but: @property void func( ref A a, int b ) ... should work. Same goes for dropping the () to zero arguments function calls. Once that needs to be a conscious decision by the programmer, my problems with UFCS are greatly reduced (though, to be fair, not completely alleviated). Yes, that mirrors my thoughts exactly. To me a.propagate(b,c) reads completely different from propagate(a,b,c), just like a.start and a.start() reads different (asking vs doing). I want a language to enforce that. When reading code I don't want to wonder if libraryobject.print() is a function that is part of an external library or if it is application code. I want that to be clear when skimming over the source. No IDE can help with that without adding clutter. I therefore find extension-methods are more suitable for objects that are self-contained (like integer and string) and less suitable for objects that are facades for complicated machinery. The module/encapsulation subsystem for language BETA allows local extensions by injecting them into library-defined slots in the AST. That way the library author get some control over what you can extend. I also don't add methods much to objects in dynamic languages where this is integral to the programming model, only as a quick hack. Subclassing is usually the better option. Which is reflected in Python by the adding of a new class type with restrictions on expanding the type.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 08:57:58 UTC, Chris wrote: On Monday, 8 June 2015 at 19:48:41 UTC, Paulo Pinto wrote: On Monday, 8 June 2015 at 19:24:47 UTC, Walter Bright wrote: On 6/8/2015 11:17 AM, Paulo Pinto wrote: Apparently modules have been pushed into a Technical Specification, and won't be ready on time for inclusion into ANSI C++ 17. https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/ So, here is another feature that D wins over C++. Looks like C++ is adopting ever more D features: proposed a syntax for declaring preconditions, postconditions, and invariants for a function in its interface (i.e. in its declaration), primarily for the purpose of static analysis and enabling compiler optimizations. Bjarne presented the latest version of his proposal for automatically generating comparison operators for class types. Unified call syntax. This proposal, by Bjarne, seeks to unify the member (x.f(y)) and non-member (f(x, y)) call syntaxes by allowing functions of either kind to be invoked by syntax of either kind. A restricted form of static_if; Extending static_assert to allow taking for the error message not just a string literal, but any constant expression that can be converted to a string literal. noexcept(auto), which basically means “deduce the noexcept-ness of this function from the noexcept-ness of the functions it calls. (This is essentially doing nothrow attribute inference.) Eric Niebler came to that meeting with a detailed and well fleshed-out design for ranges in the standard library. This is really funny. After years of ignoring or bashing and ridiculing D. Those who work with D know who useful these features are. They must have worked with it too ;) I see a problem that having those features in C++ will reduce the desire from companies to adopt D. Yes and no. In D these features have been carefully crafted to be part and parcel of the language (there are still some rough edges, but well). In C++ it's gonna be the usual glue it on top of what we have and make complicated rules in order not interfere with legacy code. In short, it's gonna be a nightmare to use and people will stick to what they know, I think. +1 the range library proposal is *ugly,* and the author did the best he could honestly. on the topic of D advancing ahead of C++, I think language built-in tuples and pattern matching would be a good start : )
Re: [OT] Modules dropped out of C++17
On 6/9/2015 12:42 AM, Shachar Shemesh wrote: Ambiguity over location of definition is something that promotes bugs. D's anti-hijacking lookup rules pretty much blunt this sort of problem.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 08:40:21 UTC, Shachar Shemesh wrote: But that's just it. With UFCS, the function no longer needs to be in the same module as the class/struct to which it is referring. In fact, that is the whole point. What you complain about again? C never had modules or whatever symbol scoping anyway. In the relevant C++ proposal, at least you can be sure that there is at most one such function. Otherwise, the linker will complain (namespaces notwithstanding). In D, you can't even say that. There may be three (or three thousand) such functions, each in its own module, and until/unless you try to import two such modules, you won't even notice it. This is how all free functions worked since the beginning (even without UFCS). It's not a feature of UFCS.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 09:16:40 UTC, weaselcat wrote: On Tuesday, 9 June 2015 at 08:57:58 UTC, Chris wrote: On Monday, 8 June 2015 at 19:48:41 UTC, Paulo Pinto wrote: On Monday, 8 June 2015 at 19:24:47 UTC, Walter Bright wrote: On 6/8/2015 11:17 AM, Paulo Pinto wrote: Apparently modules have been pushed into a Technical Specification, and won't be ready on time for inclusion into ANSI C++ 17. https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/ So, here is another feature that D wins over C++. Looks like C++ is adopting ever more D features: proposed a syntax for declaring preconditions, postconditions, and invariants for a function in its interface (i.e. in its declaration), primarily for the purpose of static analysis and enabling compiler optimizations. Bjarne presented the latest version of his proposal for automatically generating comparison operators for class types. Unified call syntax. This proposal, by Bjarne, seeks to unify the member (x.f(y)) and non-member (f(x, y)) call syntaxes by allowing functions of either kind to be invoked by syntax of either kind. A restricted form of static_if; Extending static_assert to allow taking for the error message not just a string literal, but any constant expression that can be converted to a string literal. noexcept(auto), which basically means “deduce the noexcept-ness of this function from the noexcept-ness of the functions it calls. (This is essentially doing nothrow attribute inference.) Eric Niebler came to that meeting with a detailed and well fleshed-out design for ranges in the standard library. This is really funny. After years of ignoring or bashing and ridiculing D. Those who work with D know who useful these features are. They must have worked with it too ;) I see a problem that having those features in C++ will reduce the desire from companies to adopt D. Yes and no. In D these features have been carefully crafted to be part and parcel of the language (there are still some rough edges, but well). In C++ it's gonna be the usual glue it on top of what we have and make complicated rules in order not interfere with legacy code. In short, it's gonna be a nightmare to use and people will stick to what they know, I think. +1 the range library proposal is *ugly,* and the author did the best he could honestly. also, I wonder what the assembly output using the ranges proposal looks like. I often see my range code boiled down to a few vector ops by GDC and LDC, but AFAIK a lot of effort has gone into making ranges as efficient as possible.
Re: [OT] Modules dropped out of C++17
On 09/06/15 10:21, Paulo Pinto wrote: It is no different than extension methods in .NET, Ceylon, Kotlin, multi-methods in CLOS or implicits in Scala. I never could understand that line of reasoning: Argument: So and so is bad because A Answer: X, Y, and Z also do so and so How is the answer clearing up anything? It completely ignores the reasons why so and so was claimed to be bad. I just mouse hover, press F12/Ctrl+Right Mouse and in less than 5s is the method visible. Please see my answer to Joakim. Also, you say 5 seconds as if that's a short amount of time. If it takes an automatic scanner 5 seconds, it means the amount of coverage it needs to perform is huge. This means that for any action that does not involve the scanner (e.g. writing new code, implementing a new function, deciding which function to call), you need to hold in your head the amount of state it takes your scanner 5 seconds to collect. Which leads me back to my original claim: this feature promotes bugs. Shachar
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 07:27:26 UTC, Joakim wrote: On Tuesday, 9 June 2015 at 06:54:39 UTC, Shachar Shemesh wrote: On 08/06/15 22:24, Walter Bright wrote: Unified call syntax. This proposal, by Bjarne, seeks to unify the member (x.f(y)) and non-member (f(x, y)) call syntaxes by allowing functions of either kind to be invoked by syntax of either kind. Dear god, I hope this doesn't pass. It is one of the most confusing aspects of D. It makes it close to impossible to locate the definition for a function used. Perhaps Dscanner's declaration finder (the -d flag) or DCD would make your life easier. I use Dscanner all the time and miss it when I'm stuck with grep for C nowadays: https://github.com/Hackerpilot/Dscanner https://github.com/Hackerpilot/DCD Why are you using grep for C? There are solutions. I use rtags and my own Emacs package cmake-ide. Works a treat. Atila
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 08:03:18 UTC, weaselcat wrote: what would need to be done to get dscanner fit to be part of the standard D tool chain? We're starting with dfmt and dfix.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 07:42:40 UTC, Shachar Shemesh wrote: Ambiguity over location of definition is something that promotes bugs. The technical problem of finding the definition is the least important aspect of the problem. I don't understand the problem then: you're saying you have no problem finding the possible function definitions, but have trouble making out which of several overloaded functions is the one being invoked? On Tuesday, 9 June 2015 at 08:09:01 UTC, Atila Neves wrote: Why are you using grep for C? There are solutions. I use rtags and my own Emacs package cmake-ide. Works a treat. I don't search through C headers much, just for one-off stuff like writing D bindings. I've used Exuberant Ctags before with vim for a large C++ codebase, it worked reasonably well.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 07:59:41 UTC, weaselcat wrote: simple solution: just make everything a template, and alias empty-templated functions ;) also, AFAIK in 2.068 auto return functions are getting attribute inference. Templates don't help in meeting CTFE requirements.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 06:54:39 UTC, Shachar Shemesh wrote: On 08/06/15 22:24, Walter Bright wrote: Unified call syntax. This proposal, by Bjarne, seeks to unify the member (x.f(y)) and non-member (f(x, y)) call syntaxes by allowing functions of either kind to be invoked by syntax of either kind. Dear god, I hope this doesn't pass. I agree, I have conventions in my C++ code where member functions and free functions shouldn't mix. But given C++ templates lack of type safety, I'm not surprised that BS pushes it. It also does not solve std::begin issues better than a method-extension feature would have done.
Re: [OT] Modules dropped out of C++17
On Monday, 8 June 2015 at 22:22:51 UTC, Andrei Alexandrescu wrote: On 6/8/15 1:25 PM, ponce wrote: C++'s constexpr looks broken because everything must be marked constexpre, which defeats the purpose of having compile-time code looking like runtime code. But I never had the pleasure to use it. Yeah, it's sadly quite björked. Scott Meyers and I looked at the feature and the logical conclusion for a guideline was Speculatively mark everything in sight as constexpr. That doesn't quite scale. -- Andrei Same as with @safe @nogc @nothrow @pure. If you don't have ctfeability expressed in function's contract, you have no idea how you can modify the function's implementation so that to not break other people's code. Sorry for making c++ look cute again :)
Re: [OT] Modules dropped out of C++17
On 06/09/2015 08:54 AM, Shachar Shemesh wrote: It is one of the most confusing aspects of D. It makes it close to impossible to locate the definition for a function used. close to impossible? :o) If you can find a.foo() and foo(a) without UFCS, then you can find them with UFCS.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 07:58:04 UTC, Kagamin wrote: On Monday, 8 June 2015 at 22:22:51 UTC, Andrei Alexandrescu wrote: On 6/8/15 1:25 PM, ponce wrote: C++'s constexpr looks broken because everything must be marked constexpre, which defeats the purpose of having compile-time code looking like runtime code. But I never had the pleasure to use it. Yeah, it's sadly quite björked. Scott Meyers and I looked at the feature and the logical conclusion for a guideline was Speculatively mark everything in sight as constexpr. That doesn't quite scale. -- Andrei Same as with @safe @nogc @nothrow @pure. If you don't have ctfeability expressed in function's contract, you have no idea how you can modify the function's implementation so that to not break other people's code. Sorry for making c++ look cute again :) simple solution: just make everything a template, and alias empty-templated functions ;) also, AFAIK in 2.068 auto return functions are getting attribute inference.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 07:27:26 UTC, Joakim wrote: On Tuesday, 9 June 2015 at 06:54:39 UTC, Shachar Shemesh wrote: On 08/06/15 22:24, Walter Bright wrote: Unified call syntax. This proposal, by Bjarne, seeks to unify the member (x.f(y)) and non-member (f(x, y)) call syntaxes by allowing functions of either kind to be invoked by syntax of either kind. Dear god, I hope this doesn't pass. It is one of the most confusing aspects of D. It makes it close to impossible to locate the definition for a function used. Perhaps Dscanner's declaration finder (the -d flag) or DCD would make your life easier. I use Dscanner all the time and miss it when I'm stuck with grep for C nowadays: https://github.com/Hackerpilot/Dscanner https://github.com/Hackerpilot/DCD what would need to be done to get dscanner fit to be part of the standard D tool chain?
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 08:33:04 UTC, Kagamin wrote: Extension methods are conceptually the type's methods. The type's interface is a conceptual thing, I don't think it has anything to do with physical layout of source code. This is a tricky issue. If you have structural typing (which Ada-style generics, C++ and D templates are a close, but weak, cousin to) then adding an extension method as a first class method will then change the type-resolution... which affects what kind of features you can have that use type resolution. Is the extension global or local? What if two extensions differ in semantics, but not in name? Not a problem for nominal typing, but a problem for structural/duck-like typing when you scale up.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 07:49:24 UTC, Shachar Shemesh wrote: Also, you say 5 seconds as if that's a short amount of time. If it takes an automatic scanner 5 seconds, it means the amount of coverage it needs to perform is huge. If anybody was wondering why DCD doesn't support UFCS, this is the answer. I can't find a way to make it fast, useful, or compact in terms of memory use.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 07:42:40 UTC, Shachar Shemesh wrote: I use DCD, and *for the most part* it does a reasonable job of finding the definition. It is not, however, something that excuses a language feature that makes life more difficult. Ambiguity over location of definition is something that promotes bugs. The technical problem of finding the definition is the least important aspect of the problem. Not sure what you compare it to. Even finding declaration was never an easy job in C, and definition can be anywhere in the source tree. In D symbols are at least tied to modules, so you can look only in the respective module, this never worked for C though.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 07:49:24 UTC, Shachar Shemesh wrote: Please see my answer to Joakim. Also, you say 5 seconds as if that's a short amount of time. If it takes an automatic scanner 5 seconds, it means the amount of coverage it needs to perform is huge. Probably a tooling issue, for me it works instantly for C#. This means that for any action that does not involve the scanner (e.g. writing new code, implementing a new function, deciding which function to call), you need to hold in your head the amount of state it takes your scanner 5 seconds to collect. Extension methods are conceptually the type's methods. The type's interface is a conceptual thing, I don't think it has anything to do with physical layout of source code.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 07:49:24 UTC, Shachar Shemesh wrote: On 09/06/15 10:21, Paulo Pinto wrote: It is no different than extension methods in .NET, Ceylon, Kotlin, multi-methods in CLOS or implicits in Scala. I never could understand that line of reasoning: Argument: So and so is bad because A Answer: X, Y, and Z also do so and so How is the answer clearing up anything? It completely ignores the reasons why so and so was claimed to be bad. I just mouse hover, press F12/Ctrl+Right Mouse and in less than 5s is the method visible. Please see my answer to Joakim. Also, you say 5 seconds as if that's a short amount of time. If it takes an automatic scanner 5 seconds, it means the amount of coverage it needs to perform is huge. This means that for any action that does not involve the scanner (e.g. writing new code, implementing a new function, deciding which function to call), you need to hold in your head the amount of state it takes your scanner 5 seconds to collect. Which leads me back to my original claim: this feature promotes bugs. Shachar 5 seconds was just an example. Usually it is almost instantaneous.
Re: [OT] Modules dropped out of C++17
On 09/06/15 11:17, Kagamin wrote: Not sure what you compare it to. Even finding declaration was never an easy job in C, and definition can be anywhere in the source tree. In D symbols are at least tied to modules, so you can look only in the respective module, this never worked for C though. But that's just it. With UFCS, the function no longer needs to be in the same module as the class/struct to which it is referring. In fact, that is the whole point. In the relevant C++ proposal, at least you can be sure that there is at most one such function. Otherwise, the linker will complain (namespaces notwithstanding). In D, you can't even say that. There may be three (or three thousand) such functions, each in its own module, and until/unless you try to import two such modules, you won't even notice it. Shachar
Re: [OT] Modules dropped out of C++17
On 09/06/15 11:35, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: I agree, I have conventions in my C++ code where member functions and free functions shouldn't mix. But given C++ templates lack of type safety, I'm not surprised that BS pushes it. It also does not solve std::begin issues better than a method-extension feature would have done. Actually, that's an important point for D as well. I would have a considerably less problem with UFCS had it been limited only to explicit declaration. So: void func( ref A a, int b ) ... A a; a.func(12); // Should not compile IMHO but: @property void func( ref A a, int b ) ... should work. Same goes for dropping the () to zero arguments function calls. Once that needs to be a conscious decision by the programmer, my problems with UFCS are greatly reduced (though, to be fair, not completely alleviated). Shachar
Re: [OT] Modules dropped out of C++17
On Monday, 8 June 2015 at 19:48:41 UTC, Paulo Pinto wrote: On Monday, 8 June 2015 at 19:24:47 UTC, Walter Bright wrote: On 6/8/2015 11:17 AM, Paulo Pinto wrote: Apparently modules have been pushed into a Technical Specification, and won't be ready on time for inclusion into ANSI C++ 17. https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/ So, here is another feature that D wins over C++. Looks like C++ is adopting ever more D features: proposed a syntax for declaring preconditions, postconditions, and invariants for a function in its interface (i.e. in its declaration), primarily for the purpose of static analysis and enabling compiler optimizations. Bjarne presented the latest version of his proposal for automatically generating comparison operators for class types. Unified call syntax. This proposal, by Bjarne, seeks to unify the member (x.f(y)) and non-member (f(x, y)) call syntaxes by allowing functions of either kind to be invoked by syntax of either kind. A restricted form of static_if; Extending static_assert to allow taking for the error message not just a string literal, but any constant expression that can be converted to a string literal. noexcept(auto), which basically means “deduce the noexcept-ness of this function from the noexcept-ness of the functions it calls. (This is essentially doing nothrow attribute inference.) Eric Niebler came to that meeting with a detailed and well fleshed-out design for ranges in the standard library. This is really funny. After years of ignoring or bashing and ridiculing D. Those who work with D know who useful these features are. They must have worked with it too ;) I see a problem that having those features in C++ will reduce the desire from companies to adopt D. Yes and no. In D these features have been carefully crafted to be part and parcel of the language (there are still some rough edges, but well). In C++ it's gonna be the usual glue it on top of what we have and make complicated rules in order not interfere with legacy code. In short, it's gonna be a nightmare to use and people will stick to what they know, I think. At very least they should acknowledge all of you guys for the ideas. They would never do that.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 10:48:22 UTC, Marc Schütz wrote: static assert() is your friend in this case. See also the related problem of guaranteeing that a template is When constexpr is part of the prototype you know that it isn't supposed to do substantial work. Without it, you risk the compiler spending a lot of time computing constants/tables that should be done at runtime to save compile time and object code size. And since C++ programmers expect that level of control, it would have ended up as a pragma if it was not part of the language? Not saying one way is obviously better than the other. I think LLVM (and all the open source starting points available) paves the way for performant high level languages by reducing the cost of building a backend. Maybe in some unexpected direction that fits next-gen hardware better than C-descendants.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 10:48:22 UTC, Marc Schütz wrote: static assert() is your friend in this case The point is that in D you don't need to express ctfe guarantee at all. It just works.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 07:58:04 UTC, Kagamin wrote: On Monday, 8 June 2015 at 22:22:51 UTC, Andrei Alexandrescu wrote: On 6/8/15 1:25 PM, ponce wrote: C++'s constexpr looks broken because everything must be marked constexpre, which defeats the purpose of having compile-time code looking like runtime code. But I never had the pleasure to use it. Yeah, it's sadly quite björked. Scott Meyers and I looked at the feature and the logical conclusion for a guideline was Speculatively mark everything in sight as constexpr. That doesn't quite scale. -- Andrei Same as with @safe @nogc @nothrow @pure. If you don't have ctfeability expressed in function's contract, you have no idea how you can modify the function's implementation so that to not break other people's code. Sorry for making c++ look cute again :) static assert() is your friend in this case. See also the related problem of guaranteeing that a template is nothrow/@nogc/whatever by itself (i.e. doesn't do anything that violates them), even though it cannot be marked as such because that would preclude instantiating it with certain types that aren't nothrow/@nogc.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 09:06:38 UTC, Ola Fosheim Grøstad wrote: but a problem for structural/duck-like typing when you scale up. Not a problem of cognitive complexity, though. On Tuesday, 9 June 2015 at 10:16:12 UTC, Ola Fosheim Grøstad wrote: When reading code I don't want to wonder if libraryobject.print() is a function that is part of an external library or if it is application code. I want that to be clear when skimming over the source. No IDE can help with that without adding clutter. Not sure how physical layout of source code affects understanding of libraryobject.print(). Subclassing is usually the better option. In statically typed languages you don't control types you receive from 3rd party code.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 09:33:33 UTC, Walter Bright wrote: On 6/9/2015 12:42 AM, Shachar Shemesh wrote: Ambiguity over location of definition is something that promotes bugs. D's anti-hijacking lookup rules pretty much blunt this sort of problem. It does not prevent programmers from writing hazy code or programming late at night and making mistakes. So it weakens the type system.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 06:54:39 UTC, Shachar Shemesh wrote: On 08/06/15 22:24, Walter Bright wrote: Unified call syntax. This proposal, by Bjarne, seeks to unify the member (x.f(y)) and non-member (f(x, y)) call syntaxes by allowing functions of either kind to be invoked by syntax of either kind. Dear god, I hope this doesn't pass. It is one of the most confusing aspects of D. It makes it close to impossible to locate the definition for a function used. Shachar It is no different than extension methods in .NET, Ceylon, Kotlin, multi-methods in CLOS or implicits in Scala. I just mouse hover, press F12/Ctrl+Right Mouse and in less than 5s is the method visible.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 06:54:39 UTC, Shachar Shemesh wrote: On 08/06/15 22:24, Walter Bright wrote: Unified call syntax. This proposal, by Bjarne, seeks to unify the member (x.f(y)) and non-member (f(x, y)) call syntaxes by allowing functions of either kind to be invoked by syntax of either kind. Dear god, I hope this doesn't pass. It is one of the most confusing aspects of D. It makes it close to impossible to locate the definition for a function used. Perhaps Dscanner's declaration finder (the -d flag) or DCD would make your life easier. I use Dscanner all the time and miss it when I'm stuck with grep for C nowadays: https://github.com/Hackerpilot/Dscanner https://github.com/Hackerpilot/DCD
Re: [OT] Modules dropped out of C++17
On Monday, 8 June 2015 at 22:17:34 UTC, Andrei Alexandrescu wrote: On 6/8/15 12:48 PM, Paulo Pinto wrote: I see a problem that having those features in C++ will reduce the desire from companies to adopt D. At very least they should acknowledge all of you guys for the ideas. As I said at DConf, D is the N word of C++. It's actually comical to watch the lengths at which some folks in the community go to not mention D. Anyhow, C++ playing catch up means we're doing the right things and they shoot where we were a while ago. I hope the next thing for us is Design by Introspection, which is going to knock the socks off everyone. Andrei This compile-time duck-typing thing does ring like something from the future, and it is interestingly different from C++'s concepts / Rust traits / Haskell typeclasses. It's gonna be useful whenever one wants to write a good abstraction for X (which is super hard).
Re: [OT] Modules dropped out of C++17
On 08/06/15 22:24, Walter Bright wrote: Unified call syntax. This proposal, by Bjarne, seeks to unify the member (x.f(y)) and non-member (f(x, y)) call syntaxes by allowing functions of either kind to be invoked by syntax of either kind. Dear god, I hope this doesn't pass. It is one of the most confusing aspects of D. It makes it close to impossible to locate the definition for a function used. Shachar
Re: [OT] Modules dropped out of C++17
On 09/06/15 10:27, Joakim wrote: Perhaps Dscanner's declaration finder (the -d flag) or DCD would make your life easier. I use Dscanner all the time and miss it when I'm stuck with grep for C nowadays: https://github.com/Hackerpilot/Dscanner https://github.com/Hackerpilot/DCD I use DCD, and *for the most part* it does a reasonable job of finding the definition. It is not, however, something that excuses a language feature that makes life more difficult. Ambiguity over location of definition is something that promotes bugs. The technical problem of finding the definition is the least important aspect of the problem. Shachar
Re: [OT] Modules dropped out of C++17
On 06/09/2015 02:28 PM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
On Tuesday, 9 June 2015 at 11:47:49 UTC, Kagamin wrote:
On Tuesday, 9 June 2015 at 10:48:22 UTC, Marc Schütz wrote:
static assert() is your friend in this case
The point is that in D you don't need to express ctfe guarantee at
all. It just works.
Huh? As I understood you, you asked for a guarantee that a function is
CTFEable, in order to not break other people's code. static assert()
gives you that:
static assert(__traits(compiles, { enum dummy = myFunction(); }));
What if you don't support it, but it works by accident?
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 11:39:49 UTC, Kagamin wrote: Not sure how physical layout of source code affects understanding of libraryobject.print(). One of the arguments for having separate declarations and definitions in C++ is that it provides better encapsulation (which C++ breaks for templates and inlined methods). If you have full encapsulation you know that the declaration holds. So x.print() means that the declaration for the type of x includes print(). That also affects what print() can reasonably be expected to affect. Subclassing is usually the better option. In statically typed languages you don't control types you receive from 3rd party code. True, but you can always wrap code in interfacing-references. I use this deliberately in multi-threaded code, so that I avoid calling the wrong methods on the wrong thread. E.g. multithreaded(someobject).clear() and singlethreaded(someobject).clear().
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 14:05:40 UTC, Ola Fosheim Grøstad wrote: One of the arguments for having separate declarations and definitions in C++ is that it provides better encapsulation (which C++ breaks for templates and inlined methods). If you have full encapsulation you know that the declaration holds. So x.print() means that the declaration for the type of x includes print(). Well, if you have full encapsulation, then you don't have extension methods and consequently don't have this issue. True, but you can always wrap code in interfacing-references. I use this deliberately in multi-threaded code, so that I avoid calling the wrong methods on the wrong thread. E.g. multithreaded(someobject).clear() and singlethreaded(someobject).clear(). This doesn't look like full encapsulation if the type behavior is extended this way.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 15:06:13 UTC, Kagamin wrote: Well, if you have full encapsulation, then you don't have extension methods and consequently don't have this issue. Well, you can, because you don't access object internals, but the point was exactly that extension methods can make programs harder to read. This doesn't look like full encapsulation if the type behavior is extended this way. It is not an extension. It is a function returning a reference object that holds a pointer to the object and the new interface methods you want it to have. It is explicit so it does not make programs harder to read.
Re: [OT] Modules dropped out of C++17
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 6/9/15 12:58 AM, Kagamin wrote: Same as with @safe @nogc @nothrow @pure. No, these are attributes that change the function's type; constexpr does not. Why is that better?
Re: [OT] Modules dropped out of C++17
On 6/9/15 12:58 AM, Kagamin wrote:
On Monday, 8 June 2015 at 22:22:51 UTC, Andrei Alexandrescu wrote:
On 6/8/15 1:25 PM, ponce wrote:
C++'s constexpr looks broken because everything must be marked
constexpre, which defeats the purpose of having compile-time code
looking like runtime code. But I never had the pleasure to use it.
Yeah, it's sadly quite björked. Scott Meyers and I looked at the
feature and the logical conclusion for a guideline was Speculatively
mark everything in sight as constexpr. That doesn't quite scale. --
Andrei
Same as with @safe @nogc @nothrow @pure.
No, these are attributes that change the function's type; constexpr does
not. (Plus, in D the attributes may be applied in bulk with : or {}).
If you don't have ctfeability
expressed in function's contract, you have no idea how you can modify
the function's implementation so that to not break other people's code.
Sorry for making c++ look cute again :)
I guess you could do a lot worse than using a unittest to make sure a
function is CTFEable.
Andrei
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 15:49:07 UTC, Timon Gehr wrote:
On 06/09/2015 02:28 PM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
On Tuesday, 9 June 2015 at 11:47:49 UTC, Kagamin wrote:
On Tuesday, 9 June 2015 at 10:48:22 UTC, Marc Schütz wrote:
static assert() is your friend in this case
The point is that in D you don't need to express ctfe
guarantee at
all. It just works.
Huh? As I understood you, you asked for a guarantee that a
function is
CTFEable, in order to not break other people's code. static
assert()
gives you that:
static assert(__traits(compiles, { enum dummy =
myFunction(); }));
What if you don't support it, but it works by accident?
If you don't want to support it, why _would_ you put the static
assert() in? Or do you mean something else?
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 08:06:52 UTC, Brian Schott wrote: On Tuesday, 9 June 2015 at 07:49:24 UTC, Shachar Shemesh wrote: Also, you say 5 seconds as if that's a short amount of time. If it takes an automatic scanner 5 seconds, it means the amount of coverage it needs to perform is huge. If anybody was wondering why DCD doesn't support UFCS, this is the answer. I can't find a way to make it fast, useful, or compact in terms of memory use. Resolving identifier in D is extremely complex. For instance: https://github.com/deadalnix/SDC/blob/master/libd/src/d/semantic/identifier.d
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 18:20:43 UTC, Tobias Müller wrote: And if you don't give that guarantee, well then it may just work. Or not. Or just stop working at some point in the future. It would be nice to have an operator that forces CTFE and inlining. @ct( this_is_ctfe() ) @inline( this_is_inlined() )
Re: [OT] Modules dropped out of C++17
On 6/9/15 4:06 AM, Brian Schott wrote: On Tuesday, 9 June 2015 at 07:49:24 UTC, Shachar Shemesh wrote: Also, you say 5 seconds as if that's a short amount of time. If it takes an automatic scanner 5 seconds, it means the amount of coverage it needs to perform is huge. If anybody was wondering why DCD doesn't support UFCS, this is the answer. I can't find a way to make it fast, useful, or compact in terms of memory use. I can't see how a UFCS lookup is any slower than a normal function lookup. It's just a rewrite. i.e.: a.foo 1. try finding member foo on type a. 2. try finding function foo a. If found, find overload that will take a. What happens as you type: foo(a ??? how is it any different? -Steve
Re: [OT] Modules dropped out of C++17
Kagamin s...@here.lot wrote: On Tuesday, 9 June 2015 at 10:48:22 UTC, Marc Schütz wrote: static assert() is your friend in this case The point is that in D you don't need to express ctfe guarantee at all. It just works. In other words you have no guarantee. If you want the guarantee you have to ensure it via static assert or unittest and you have to document it. The constexpr attribute covers both at once. And if you don't give that guarantee, well then it may just work. Or not. Or just stop working at some point in the future.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 20:01:24 UTC, Walter Bright wrote: On 6/9/2015 4:25 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: When constexpr is part of the prototype you know that it isn't supposed to do substantial work. That doesn't follow. What doesn't follow? All my constexpr functions are simple. I absolutely don't want to solve N-Queens problems at CT. Without it, you risk the compiler spending a lot of time computing constants/tables that should be done at runtime to save compile time and object code size. And since C++ programmers expect that level of control, it would have ended up as a pragma if it was not part of the language? This is just made up problems. Nah, sometimes I want my big lookup tables to be evaluated at runtime so I don't get bloated binaries. But neither C++ or D cuts it. Because sometimes I want the code that uses constant indexing to look it up in the LUT, but actually generate the LUT at runtime. Can D check that a parameter is a CT value so that one can overload on it? That would work.
Re: [OT] Modules dropped out of C++17
On 6/9/2015 4:25 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: When constexpr is part of the prototype you know that it isn't supposed to do substantial work. That doesn't follow. Without it, you risk the compiler spending a lot of time computing constants/tables that should be done at runtime to save compile time and object code size. And since C++ programmers expect that level of control, it would have ended up as a pragma if it was not part of the language? This is just made up problems.
Re: [OT] Modules dropped out of C++17
On 6/9/2015 2:58 AM, Jacob Carlborg wrote: Even though the compiler makes sure there's no ambiguity it might not always be so easy to find the definition. I usually try to select identifiers that are easy to grep. So unless one has a penchant for naming functions f(), in practice it isn't a significant issue.
Re: [OT] Modules dropped out of C++17
On 09/06/15 22:39, Walter Bright wrote: I usually try to select identifiers that are easy to grep. So unless one has a penchant for naming functions f(), in practice it isn't a significant issue. The difference between theory and practice is that, in theory, there is no difference between theory and practice. But in practice, there is. (Too ashamed to admit I'm quoting Yogi Berra here, so I won't :-). In practice, when your code gets big enough in a certain field, similar names are pretty much unavoidable. Admittedly, this is mostly around variable names. I lost count over the number of variables called diskIdx I have. While not exactly duplicate per-se, there is also a (member) function by that name. Try to find where diskIdx is defined, and you /will/ get swamped. Shachar
Re: [OT] Modules dropped out of C++17
On 6/9/2015 4:47 AM, Kagamin wrote: On Tuesday, 9 June 2015 at 10:48:22 UTC, Marc Schütz wrote: static assert() is your friend in this case The point is that in D you don't need to express ctfe guarantee at all. It just works. Also, only the particular path the CTFE interpreter takes through the function needs to be CTFE'able, not all the paths. This makes it starkly different from constexpr.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 21:40:29 UTC, Walter Bright wrote: You've invented your own definition of constexpr; you would as productively tagged your C++ functions with /*simple*/. Kind of yes, but since C++ requires it I actually use it too. But in D, you can invent your own attribute @simple, and then tag functions with that. I could, but D would not check it?
Re: [OT] Modules dropped out of C++17
On 06/09/2015 06:27 PM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
On Tuesday, 9 June 2015 at 15:49:07 UTC, Timon Gehr wrote:
On 06/09/2015 02:28 PM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
On Tuesday, 9 June 2015 at 11:47:49 UTC, Kagamin wrote:
On Tuesday, 9 June 2015 at 10:48:22 UTC, Marc Schütz wrote:
static assert() is your friend in this case
The point is that in D you don't need to express ctfe guarantee at
all. It just works.
Huh? As I understood you, you asked for a guarantee that a function is
CTFEable, in order to not break other people's code. static assert()
gives you that:
static assert(__traits(compiles, { enum dummy = myFunction(); }));
What if you don't support it, but it works by accident?
If you don't want to support it, why _would_ you put the static assert()
in? Or do you mean something else?
Basically, the scenario that *lack* of constexpr is able to successfully
avoid by default is that you write a function that just so happens to
work in CTFE but doesn't in the next release, and your dependencies
break (in D you'd need to add an explicit if(__ctfe) assert(0), or
similar.) I.e. lack of constexpr is a kind of enforced documentation.
Anyway, I don't think this is worth the additional trouble.
Re: [OT] Modules dropped out of C++17
On 06/09/2015 08:33 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Tuesday, 9 June 2015 at 18:20:43 UTC, Tobias Müller wrote: And if you don't give that guarantee, well then it may just work. Or not. Or just stop working at some point in the future. It would be nice to have an operator that forces CTFE and inlining. @ct( this_is_ctfe() ) @inline( this_is_inlined() ) enum ct(alias a)=a;
Re: [OT] Modules dropped out of C++17
On 6/9/2015 1:25 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Tuesday, 9 June 2015 at 20:01:24 UTC, Walter Bright wrote: On 6/9/2015 4:25 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: When constexpr is part of the prototype you know that it isn't supposed to do substantial work. That doesn't follow. What doesn't follow? All my constexpr functions are simple. You've invented your own definition of constexpr; you would as productively tagged your C++ functions with /*simple*/. But in D, you can invent your own attribute @simple, and then tag functions with that.
Re: [OT] Modules dropped out of C++17
On 6/9/2015 1:06 PM, Shachar Shemesh wrote: In practice, when your code gets big enough in a certain field, similar names are pretty much unavoidable. Admittedly, this is mostly around variable names. I lost count over the number of variables called diskIdx I have. While not exactly duplicate per-se, there is also a (member) function by that name. Try to find where diskIdx is defined, and you /will/ get swamped. First off, D does not allow shadowing local variable declarations. Secondly, if you've got a lot of global variables, you've got a program design problem anyway. And lastly, naming everything diskIdx is a problem of your own creation. You could design a language that does not allow any duplicate names anywhere, and no scoping rules would be required. But there's a reason no such language has caught on - it does not scale and is unusable. I take that back, early BASIC implementations did have such. You could only have single letter names followed by a single digit, and all names were global and hence must be unique. What a relief to leave that behind.
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 11:47:49 UTC, Kagamin wrote:
On Tuesday, 9 June 2015 at 10:48:22 UTC, Marc Schütz wrote:
static assert() is your friend in this case
The point is that in D you don't need to express ctfe guarantee
at all. It just works.
Huh? As I understood you, you asked for a guarantee that a
function is CTFEable, in order to not break other people's
code. static assert() gives you that:
static assert(__traits(compiles, { enum dummy = myFunction();
}));
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 12:28:04 UTC, Marc Schütz wrote: Huh? As I understood you, you asked for a guarantee that a function is CTFEable, in order to not break other people's code. I mean http://forum.dlang.org/post/ml54jr$107j$1...@digitalmars.com
Re: [OT] Modules dropped out of C++17
On 9 June 2015 at 16:54, Shachar Shemesh via Digitalmars-d digitalmars-d@puremagic.com wrote: On 08/06/15 22:24, Walter Bright wrote: Unified call syntax. This proposal, by Bjarne, seeks to unify the member (x.f(y)) and non-member (f(x, y)) call syntaxes by allowing functions of either kind to be invoked by syntax of either kind. Dear god, I hope this doesn't pass. It is one of the most confusing aspects of D. It makes it close to impossible to locate the definition for a function used. Just press F12 ;)
Re: [OT] Modules dropped out of C++17
On 6/9/2015 4:02 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Tuesday, 9 June 2015 at 21:40:29 UTC, Walter Bright wrote: You've invented your own definition of constexpr; you would as productively tagged your C++ functions with /*simple*/. Kind of yes, but since C++ requires it I actually use it too. But in D, you can invent your own attribute @simple, and then tag functions with that. I could, but D would not check it? I'm bemused by the argument that D is deficient because it doesn't implement a non-existent feature of C++. You're smart, capable, and well educated in programming. You have great potential for contributing, which is why I answer some of these posts. I'm hoping to entice you to contribute in the substantial way that I know you can.
Re: [OT] Modules dropped out of C++17
On 06/09/2015 04:58 AM, Shachar Shemesh wrote: I would have a considerably less problem with UFCS had it been limited only to explicit declaration. That's how it works in C#. That was actually my first introduction with extension methods, and then when UFCS was added to D, I used to be pretty vocally opposed to it being implicit. But I learned to live with it, and then I eventually I realized it was basically *never* causing me any real trouble, and now I rather like not having the cognitive load of would this be better as an extension method or not? every time I define a function. Plus, I don't have to deal with the issue of calling a func where *my* code could have been much cleaner had the func's author made it an extension method, but they didn't, so I'm stuck dealing with it or going to the bother and mess of a wrapper. I see it as a stylistic issue, now. Let the caller use whatever works best for their own code. Sure, it makes it possible for the caller the use UFCS inappropriately and obfuscate their code in goofy ways, but in practice this is almost never a real issue. And besides, pretty much *any* feature can be abused and obfuscate code. Ex: Nothing prevents me from naming a file-loading function save (BTW, I've actually seen that in commercial production code - wasted half a week figuring that one out), but being able to choose arbitrary identifier names is still a good thing.
Re: [OT] Modules dropped out of C++17
On 10/06/15 00:29, Walter Bright wrote: First off, D does not allow shadowing local variable declarations. Secondly, if you've got a lot of global variables, you've got a program design problem anyway. And lastly, naming everything diskIdx is a problem of your own creation. The first one is called so because it names the index of the disk within a RAID stripe. It's probably an iterator. How would you call the second time I use such an iterator? You might argue that the function that extracts the disk index should be named something more verbose (i.e. - extractTheDiskIndex), but then you are just repeating Ola's criticism[1] of D as if it is a desirable thing. People on this list hold a certain paradigm in their head when they make design decisions. That's fine, except if you hold on to this paradigm and assume anything that violates it is bad code, you are going to end up with Go: a language only fit for those problems that happen to fall within that paradigm. People have preconceptions on how code should look like. I would humbly like to ask people to stop -assuming- that anything that violates them is bad code. Shachar 1 - http://forum.dlang.org/post/uvajlhfztejvwnubs...@forum.dlang.org
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 07:27:26 UTC, Joakim wrote: stuck with grep for C Eww. Have you tried cscope? -Wyatt
Re: [OT] Modules dropped out of C++17
On Monday, 8 June 2015 at 18:57:17 UTC, ponce wrote: I can't imagine the weird look-up rules that will be made for a translation unit both using modules and traditional headers. At the end of the day, another set of rules for C++ers to remembers. I wonder when they will realize that a clean break is necessary. 36 years is far too long for a language to keep building on top of the past. Intel has been hurt by this with x86 recently, probably Microsoft with Windows too.
Re: [OT] Modules dropped out of C++17
On 08-Jun-2015 22:24, Walter Bright wrote: On 6/8/2015 11:17 AM, Paulo Pinto wrote: Apparently modules have been pushed into a Technical Specification, and won't be ready on time for inclusion into ANSI C++ 17. https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/ So, here is another feature that D wins over C++. Looks like C++ is adopting ever more D features: And they seem to almost have CTFE(!) From wiki on C++14: C++11 introduced the concept of a constexpr-declared function; a function which could be executed at compile time. Their return values could be consumed by operations that require constant expressions, such as an integer template argument. However, C++11 constexpr functions could only contain a single expression that is returned (as well as static_asserts and a small number of other declarations). C++14 relaxes these restrictions. Constexpr-declared functions may now contain the following:[5] Any declarations except: static or thread_local variables. Variable declarations without initializers. The conditional branching statements if and switch. All looping statements, including range-based for. Expressions which change the value of an object if the lifetime of that object began within the constant expression function. This includes calls to any non-const constexpr-declared non-static member functions. goto statements are forbidden in C++14 relaxed constexpr-declared functions. -- Dmitry Olshansky
Re: [OT] Modules dropped out of C++17
On Monday, 8 June 2015 at 19:17:03 UTC, Joakim wrote: On Monday, 8 June 2015 at 18:57:17 UTC, ponce wrote: I can't imagine the weird look-up rules that will be made for a translation unit both using modules and traditional headers. At the end of the day, another set of rules for C++ers to remembers. I wonder when they will realize that a clean break is necessary. 36 years is far too long for a language to keep building on top of the past. Intel has been hurt by this with x86 recently, probably Microsoft with Windows too. There's no point in C++ having a clean break. If you're doing that, you might as well just create a new language like D. If C++ had a clean break, it wouldn't be C++ anymore, and many of the folks who continue to use C++ are the ones who want it to be backwards compatible. Arguably, if anything, languages like D and Rust _are_ the clean break. - Jonathan M Davis
[OT] Modules dropped out of C++17
Apparently modules have been pushed into a Technical Specification, and won't be ready on time for inclusion into ANSI C++ 17. https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/ So, here is another feature that D wins over C++. -- Paulo
Re: [OT] Modules dropped out of C++17
On Mon, 08 Jun 2015 18:24:13 + Dennis Ritchie via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 8 June 2015 at 18:17:13 UTC, Paulo Pinto wrote: Apparently modules have been pushed into a Technical Specification, and won't be ready on time for inclusion into ANSI C++ 17. https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/ So, here is another feature that D wins over C++. -- Paulo Great news for fans of D, of course :) Yep, until C++ will have modules support I will stay on D ;)
Re: [OT] Modules dropped out of C++17
On 6/8/2015 11:17 AM, Paulo Pinto wrote: Apparently modules have been pushed into a Technical Specification, and won't be ready on time for inclusion into ANSI C++ 17. https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/ So, here is another feature that D wins over C++. Looks like C++ is adopting ever more D features: proposed a syntax for declaring preconditions, postconditions, and invariants for a function in its interface (i.e. in its declaration), primarily for the purpose of static analysis and enabling compiler optimizations. Bjarne presented the latest version of his proposal for automatically generating comparison operators for class types. Unified call syntax. This proposal, by Bjarne, seeks to unify the member (x.f(y)) and non-member (f(x, y)) call syntaxes by allowing functions of either kind to be invoked by syntax of either kind. A restricted form of static_if; Extending static_assert to allow taking for the error message not just a string literal, but any constant expression that can be converted to a string literal. noexcept(auto), which basically means “deduce the noexcept-ness of this function from the noexcept-ness of the functions it calls. (This is essentially doing nothrow attribute inference.) Eric Niebler came to that meeting with a detailed and well fleshed-out design for ranges in the standard library.
Re: [OT] Modules dropped out of C++17
On Monday, 8 June 2015 at 18:17:13 UTC, Paulo Pinto wrote: Apparently modules have been pushed into a Technical Specification, and won't be ready on time for inclusion into ANSI C++ 17. https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/ So, here is another feature that D wins over C++. -- Paulo Great news for fans of D, of course :)
Re: [OT] Modules dropped out of C++17
On Monday, 8 June 2015 at 18:17:13 UTC, Paulo Pinto wrote: Apparently modules have been pushed into a Technical Specification, and won't be ready on time for inclusion into ANSI C++ 17. https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/ So, here is another feature that D wins over C++. -- Paulo I can't imagine the weird look-up rules that will be made for a translation unit both using modules and traditional headers. At the end of the day, another set of rules for C++ers to remembers.
Re: [OT] Modules dropped out of C++17
On Monday, 8 June 2015 at 19:24:47 UTC, Walter Bright wrote: On 6/8/2015 11:17 AM, Paulo Pinto wrote: Apparently modules have been pushed into a Technical Specification, and won't be ready on time for inclusion into ANSI C++ 17. https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/ So, here is another feature that D wins over C++. Looks like C++ is adopting ever more D features: proposed a syntax for declaring preconditions, postconditions, and invariants for a function in its interface (i.e. in its declaration), primarily for the purpose of static analysis and enabling compiler optimizations. Bjarne presented the latest version of his proposal for automatically generating comparison operators for class types. Unified call syntax. This proposal, by Bjarne, seeks to unify the member (x.f(y)) and non-member (f(x, y)) call syntaxes by allowing functions of either kind to be invoked by syntax of either kind. A restricted form of static_if; Extending static_assert to allow taking for the error message not just a string literal, but any constant expression that can be converted to a string literal. noexcept(auto), which basically means “deduce the noexcept-ness of this function from the noexcept-ness of the functions it calls. (This is essentially doing nothrow attribute inference.) Eric Niebler came to that meeting with a detailed and well fleshed-out design for ranges in the standard library. I see a problem that having those features in C++ will reduce the desire from companies to adopt D. At very least they should acknowledge all of you guys for the ideas.
Re: [OT] Modules dropped out of C++17
On Monday, 8 June 2015 at 19:17:03 UTC, Joakim wrote: On Monday, 8 June 2015 at 18:57:17 UTC, ponce wrote: I can't imagine the weird look-up rules that will be made for a translation unit both using modules and traditional headers. At the end of the day, another set of rules for C++ers to remembers. I wonder when they will realize that a clean break is necessary. 36 years is far too long for a language to keep building on top of the past. Intel has been hurt by this with x86 recently, probably Microsoft with Windows too. That is why Microsoft is going forward with WinRT.
Re: [OT] Modules dropped out of C++17
On Monday, 8 June 2015 at 19:48:41 UTC, Paulo Pinto wrote: I see a problem that having those features in C++ will reduce the desire from companies to adopt D. There is certainly some truth to that, but I think that it's pretty clear that in most cases, they can't do as good a job of it as D, simply because they have too much baggage in the language. And as long as we continue to improve D, we'll stay ahead of them anyway. At very least they should acknowledge all of you guys for the ideas. Perhaps, but we're all borrowing from each other all the time, and it's frequently the case that acknowledgement isn't given - and when it is, at least some of the time, it's given to someone who copied the idea from someone else. Sure, it might be nice if the C++ folks acknowledged that more of what they're adding to C++ came from D, but really, we just want them to start using D. :) And Andrei actually pointed out in a panel at dconf that he doesn't care about getting credit. So, I don't think that Walter or Andrei are all that worried about it. Still, I thought that it was pretty sad when Walter pointed out to me that he'd recently heard/read someone state that CTFE was inspired by C++'s constexpr. I have to laugh at it though. What matters at the end of the day is if we can make D a successful language that we want to use and not whether other folks give us credit when they borrow our ideas (much as it would be nice to get credit from time to time), especially when you consider how many ideas we borrowed from elsewhere without really worrying about giving credit. - Jonathan M Davis
Re: [OT] Modules dropped out of C++17
On 6/8/15 1:25 PM, ponce wrote: C++'s constexpr looks broken because everything must be marked constexpre, which defeats the purpose of having compile-time code looking like runtime code. But I never had the pleasure to use it. Yeah, it's sadly quite björked. Scott Meyers and I looked at the feature and the logical conclusion for a guideline was Speculatively mark everything in sight as constexpr. That doesn't quite scale. -- Andrei
Re: [OT] Modules dropped out of C++17
On Monday, 8 June 2015 at 19:57:34 UTC, Dmitry Olshansky wrote: And they seem to almost have CTFE(!) From wiki on C++14: C++11 introduced the concept of a constexpr-declared function; a function which could be executed at compile time. Their return values could be consumed by operations that require constant expressions, such as an integer template argument. However, C++11 constexpr functions could only contain a single expression that is returned (as well as static_asserts and a small number of other declarations). C++14 relaxes these restrictions. Constexpr-declared functions may now contain the following:[5] Any declarations except: static or thread_local variables. Variable declarations without initializers. The conditional branching statements if and switch. All looping statements, including range-based for. Expressions which change the value of an object if the lifetime of that object began within the constant expression function. This includes calls to any non-const constexpr-declared non-static member functions. goto statements are forbidden in C++14 relaxed constexpr-declared functions. C++'s constexpr looks broken because everything must be marked constexpre, which defeats the purpose of having compile-time code looking like runtime code. But I never had the pleasure to use it.
Re: [OT] Modules dropped out of C++17
On 6/8/15 12:48 PM, Paulo Pinto wrote: I see a problem that having those features in C++ will reduce the desire from companies to adopt D. At very least they should acknowledge all of you guys for the ideas. As I said at DConf, D is the N word of C++. It's actually comical to watch the lengths at which some folks in the community go to not mention D. Anyhow, C++ playing catch up means we're doing the right things and they shoot where we were a while ago. I hope the next thing for us is Design by Introspection, which is going to knock the socks off everyone. Andrei
Re: [OT] Modules dropped out of C++17
On 06/08/2015 03:55 PM, Jonathan M Davis wrote: On Monday, 8 June 2015 at 19:17:03 UTC, Joakim wrote: I wonder when they will realize that a clean break is necessary. 36 years is far too long for a language to keep building on top of the past. Intel has been hurt by this with x86 recently, probably Microsoft with Windows too. There's no point in C++ having a clean break. If you're doing that, you might as well just create a new language like D. If C++ had a clean break, it wouldn't be C++ anymore, and many of the folks who continue to use C++ are the ones who want it to be backwards compatible. Arguably, if anything, languages like D and Rust _are_ the clean break. Exactly the point. A clean break is both needed and available, however, gigantic resources are still being poured into patching up C++ anyway, instead of putting those resources into finally jumping ship. C++ is programmer heroin.
Re: [OT] Modules dropped out of C++17
On 6/8/15 2:43 PM, Tobias Müller wrote: ponce cont...@gam3sfrommars.fr wrote: C++'s constexpr looks broken because everything must be marked constexpre, which defeats the purpose of having compile-time code looking like runtime code. But I never had the pleasure to use it. constexpr functions are just as well runtime functions. They are only annotated that they are usable in a constant expression. I don't think it's fair to call that broken regarding all the attributes that D functions can take... A job well done doesn't quite spring to mind, either. FWIW, a reference to D came about on http://www.reddit.com/r/programming/comments/392jxf/modules_wont_make_it_in_c17/. Andrei
Re: [OT] Modules dropped out of C++17
ponce cont...@gam3sfrommars.fr wrote: C++'s constexpr looks broken because everything must be marked constexpre, which defeats the purpose of having compile-time code looking like runtime code. But I never had the pleasure to use it. constexpr functions are just as well runtime functions. They are only annotated that they are usable in a constant expression. I don't think it's fair to call that broken regarding all the attributes that D functions can take... Tobi
Re: [OT] Modules dropped out of C++17
On Monday, 8 June 2015 at 19:47:07 UTC, Paulo Pinto wrote: That is why Microsoft is going forward with WinRT. It is nice that they're updating the APIs, but I heard that a lot of it is just wrappers around old ones. The bigger issue is that Windows 7 and 8 (haven't tried the preview builds for 10) both feel noticeably slower to me on the _same_ hardware than FreeBSD or linux. I bet backwards compatibility has a part to play in that. On Monday, 8 June 2015 at 19:55:34 UTC, Jonathan M Davis wrote: On Monday, 8 June 2015 at 19:17:03 UTC, Joakim wrote: I wonder when they will realize that a clean break is necessary. 36 years is far too long for a language to keep building on top of the past. Intel has been hurt by this with x86 recently, probably Microsoft with Windows too. There's no point in C++ having a clean break. If you're doing that, you might as well just create a new language like D. If C++ had a clean break, it wouldn't be C++ anymore, and many of the folks who continue to use C++ are the ones who want it to be backwards compatible. Arguably, if anything, languages like D and Rust _are_ the clean break. They could do something like D when it jumped to 2.0, except with better migration paths. With some careful planning and automated source conversion tools nowadays, it doesn't have to be that bad. The idea is you keep the C++ knowledge that is accumulated by all those devs over the years, but make breaking changes that allow the language to get much better and cleaner. One of the main changes I'd pursue is getting rid of the preprocessor, though I don't know how feasible that is. You may be right that the C++ crowd is now mostly legacy-oriented and wouldn't want such a change, while those who want something different are already moving on to D and Rust, but that doesn't speak too well for the future viability of C++. ;)
