CTFE ^^ (pow)

Manu turkeyman at gmail.com
Fri Mar 23 18:09:01 UTC 2018


On 23 March 2018 at 01:36, Nick Sabalausky (Abscissa) via
Digitalmars-d <digitalmars-d at puremagic.com> wrote:
> On 03/23/2018 03:35 AM, Jordan Wilson wrote:
>>
>>
>> I suppose it's about finding that balance between growing the D user base,
>> and trying to get said user base to give back.
>>
>> Say I was offered a car with no windscreen...I have 3 responses:
>> 1. Cool! I'll put in a windscreen myself, as this car has a great engine.
>> 2. Thanks. This car does a great job getting from a to b, pity about all
>> these bugs flying in my face though. Wish I knew more about windscreens.
>> 3. No thank you, I'll just stick with the train. Nice spinner rims, btw.
>>
>> Regarding D, I fall into (2), but sometimes I wonder if catching the train
>> would be easier...
>
>
> I used to be (2) with D, but that was something like ten years ago. At this
> point, it's more like a brand new sedan, well-built, reasonably priced,
> great mileage, a few minor things I've tweaked or done differently if I had
> a magic wand, but otherwise a car that leaves me wondering "Why are people
> whining about the lack of spinner support and iPhone whiz-bangery? Big
> effing deal."
>
> That's NOT a comment on Manu's OP here, of course. Something like "Why is
> x^^y *still* not CTFE-able???" is the kind of thing I completely sympathize
> with. Can't imagine that sort of thing being a blocker though, especially if
> I were still doing a lot of work in C or C++.

Like, in this particular project, being able to generate all tables at
compile time is the thing that distinguishes the D code from the C++
code; it's the *whole point*... If I have to continue to generate
tables offline and paste big tables of data in the source code (and
then re-generate them manually when I change something); then
situation is identical to C++, therefore, stick with C++.\

This is the practical reality with a lot of my outstanding issues with
D; we've covered an awful lot of ground in 10 years, but basic
outstanding issues like not being able to pass an rvalue as ref makes
the D code longer and uglier than the C++ code it's meant to replace.
There's no argument that can be made that advocates leaving C++
(established, entrenched) for an emerging language like D, when the
case-study is longer+uglier in D.

My experience today is; D can generate machinery that C++ can't even
dream of, which is awesome, but that usually represents a tiny
fraction of your code, usually packed up in a tight little box. For
the majority of 'just code that you write', D's biggest contributors
are ranges+slices, but in my experience (migrating C++ to D), that
stuff doesn't emerge until a couple of iterations after migration.
The initial migration focuses on translation, and when super-simple
code gets longer and uglier, that's not a good look, and tends to stop
people dead in their tracks.
And it's basically inexcusable. The most common frequent code that you
write shouldn't be longer/uglier in D. We need to be able to
demonstrate that the common case gets better (or at least stays the
same) just as much as the obscure and contrived case.


More information about the Digitalmars-d mailing list