How to convert C to D using compiler? (page 3)

December 10, 2021

Re: How to convert C to D using compiler?

Posted by Max Samukha
in reply to Guillaume Piolat

Permalink

Max Samukha

Posted in reply to Guillaume Piolat

Permalink

On Wednesday, 8 December 2021 at 14:41:39 UTC, Guillaume Piolat wrote:

On Wednesday, 8 December 2021 at 14:30:46 UTC, Max Samukha wrote:

On Wednesday, 8 December 2021 at 13:13:05 UTC, Guillaume Piolat wrote:

Disagree.
For example SIMD, array ops, DUB improved and transitionned from unusable to workhorse.
Stuff that no one cares about, on the other hand, gets in the limbo zone much longer.

I disagree in my turn. There is a clear pattern: a new cool feature is introduced; people try to use it but give up because the feature is half-implemented/buggy; then, a few years later, the feature gets deprecated because "nobody used it".

I struggle to find an example honestly?

There used to be such early bumps with UDAs or nothrow, or ranges.
For a decade or so, arrays ops simply crashed DMD with optimizations on. Now they work. Brings value for the daily D programmer actually.

Again I was a big user of builtin complexes, and loudly compagined against their removal.
When removal day came, it was very little work and worked without penalty or adverse effect.
So in the end the D core team was right not to listen to me... and now it is argued on the D forums that complex numbers were removed as if it was a bad thing and people were impacted. Well, no, was a good change.

Are you sure it's not a form of Stockholm syndrome? Why is the change good?

On Friday, 10 December 2021 at 02:51:11 UTC, Max Samukha wrote:

Are you sure it's not a form of Stockholm syndrome? Why is the change good?

For sure there is some high degree of Stockholm, with something as addictive as D. :)

But in this case:

makes the language and implementation a tiny easier. If it makes compiler engineers happy then it's a positive (afaik some wanted to kill builtin complex with fire).
as a heavy complex number users: you don't really write that much literals often at all. 80% of these complex literals are zero and one (for which aliases would be maybe nice in std.complex btw)
Complex literals always seemed a little un-D to me:
Complex!double(-2.1039 , 2.6575)
yields less questions about operator priority than:
-2.1039 + 2.6575i
We have to remember cfloat/cdouble/creal also introduced the ifloat/idouble/ireal types.

Also the i is easily misread in 2.6575i, so there there was less fanfare about using complex numbers. It falls under "short syntax for rarely used thing" trap to me.
a lot of the code using complex numbers separates imaginary and real values in separate arrays. That, or SIMD code, erase the type anyway.

On Fri, Dec 10, 2021 at 05:49:44PM +0000, Guillaume Piolat via Digitalmars-d wrote: [...] > - as a heavy complex number users: you don't really write _that_ much literals often at all. 80% of these complex literals are zero and one (for which aliases would be maybe nice in std.complex btw) > > - Complex literals always seemed a little un-D to me: > Complex!double(-2.1039 , 2.6575) Hmm, technically you *could* do something like: enum i = Complex!double(0.0, 1.0); which then lets you write: -2.1039 + 2.2.6575*i of course, this then depends on the optimizer to optimize away the redundant operation. But it would be more-or-less almost as readable as built-in complex literals. T -- Ð–Ð¸Ð»-Ð±Ñ‹Ð» ÐºÐ¾Ñ€Ð¾Ð»ÑŒ ÐºÐ¾Ð³Ð´Ð°-Ñ‚Ð¾, Ð¿Ñ€Ð¸ Ð½Ñ‘Ð¼ Ð±Ð»Ð¾Ñ…Ð° Ð¶Ð¸Ð»Ð°.

Forums