On 11/18/21 8:07 AM, Ola Fosheim Grøstad wrote:

Ironically, i is almost never a global identifier. Using it for a global identifier works because UFCS is not allowed on locals.

import std.complex;

auto i(double v)
{
    return complex(0, v);
}
void main()
{
    int i = 5;
    auto c = (6 + 2.5.i - 1 + 3.i) / 3.i;
}

-Steve

On Thursday, 18 November 2021 at 13:27:15 UTC, Steven Schveighoffer wrote:

But you would have to stuff it into std.complex for it to be a library feature. So if someone else uses i(double) it would mess up everything.

That is not what Rumba asked for, he "asked" for something that was simple to use.

On Thursday, 18 November 2021 at 04:24:56 UTC, rumbu wrote:

I don't see "a better C" and "a general purpose language" as mutually exclusive. Do you disagree?

As you've mentioned, we're not going to agree. I don't think this is failing to evolve either since it's by design.

Inheritance (subtyping) and value types don't mix.

Could you please explain what these mean?

What's missing?

AFAIC this is an anti-pattern. IMHO, in OOP, there should be a switch exactly in one place in the program, and that's where instances get created. I don't know why anyone would want to recreate the functionality of the virtual table in an ad-hoc way.

Multiple dispatch blurs this, however.

How would this work?

In my view it's not really about pleasing the GC haters as much as it's acknowledging that the GC isn't always the best choice, and making sure that we can write memory-safe programs without it.

I believe it is, yes.

Library solution:

auto c = (6 + 2.i - 1 + 3.i) / 3.i;

I'd disagree it's "no contest". I think that 2021 Walter would disagree as well but he can disprove me here if not the case.

On Thursday, 18 November 2021 at 13:26:43 UTC, Adam D Ruppe wrote:

That's a rather pedantic statement.

Oh well, then nothing user defined is global, everything is nested within something else.

On Wednesday, 17 November 2021 at 21:59:51 UTC, Ola Fosheim Grøstad wrote:

No plans right now. Refresh my memory: what are the main issues?

On 11/18/21 8:25 AM, Tejas wrote:

D is quite amazing, especially with some of these syntax sugar features ;)

The strawman is from the D1 page, it compares its current implementation to a fictitious complex number implementation (that didn't exist back then), making it look as bad as possible.

I'm using the actual implementation of the library that now does exist. Note that UFCS does not exist in D1 for anything other than arrays, so in D1 that rewrite is not possible.

The i function is not in std.complex, which is a shame, I think it should be. But I've never used complex numbers so I haven't cared.

-Steve

On Thursday, 18 November 2021 at 13:37:28 UTC, Atila Neves wrote:

I don't know about the other stuff, but explicit interface implementation is this:
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/interfaces/explicit-interface-implementation

On Wednesday, 17 November 2021 at 23:45:31 UTC, Ola Fosheim Grøstad wrote:

And those feature would be...?