On Saturday, June 03, 2017 22:38:24 H. S. Teoh via Digitalmars-d wrote: > On Sat, Jun 03, 2017 at 03:00:56PM -0700, Ali Çehreli via Digitalmars-d wrote: > > On 06/03/2017 12:12 PM, Steven Schveighoffer wrote: > > > I'd say this deserves a blog post but it would be too short. > > > > I made many good friends at C++Now. Some of them know Atila from > > CppCon and other C++ conferences. (Beer involved. :) ) They told me > > Atila would routinely tell them during C++ presentations "This > > wouldn't be a talk at a DConf; it's a language feature in D." :) > > [...] > > In this case, I'd say "this wouldn't be an article about D; it's a > language feature." :-D > > Though I'd say we *could* add meat to the article by explaining what > exactly CTFE is, how it works, and why you could just call the standard > library sort at compile-time and have it Just Work(tm) without having to > jump through hoops. > > And perhaps demonstrate how easy it is to do this not just with sort, > but with far more complex things. In fact, significant chunks of Phobos > are now available at CTFE. For example, you can call std.format at > compile-time to perform some pretty hairy string formatting and have the > result baked into your executable so that you incur none of the cost of > computing it at runtime. > > The best part of all this is, as long as you have already written > runtime code that's CTFE-compatible, you don't have to do anything else > to make it work at compile-time. No messing around with constexpr, no > awkward special syntax, no need to jump through hoops, invoke arcane > black magic, etc.. Just call the code with normal runtime syntax from an > expression whose value needs to be known at compile-time, and the > compiler does the rest of you. > > And if you need a particular functionality both at compile-time and > during runtime, there's no need to write it twice in two different > sublanguages. You just write one function once, and call it from both > CTFE and at runtime. It Just Works(tm). > > Then we could add the icing on the cake by showing off one of > Andrei's(?) little gems in std.random: a RNG generator that checks *at > compile-time* whether a particular set of RNG parameters would produce a > poor-quality RNG, and abort with a compile-error if so. Meaning that if > the thing compiles at all, you have a minimum quality guarantee. (This > particular gem is described in detail in TDPL, btw, and is one of the > things about D that blew me away when I first read it.)
Be careful, or Mike will start hounding you to write the actual article. ;) - Jonathan M Davis
