November 18
On Thursday, 18 November 2021 at 13:07:28 UTC, Ola Fosheim Grøstad wrote:
> How can you bind something global to a common identifier like ```i```?

That's not global.

November 18

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

>

On Thursday, 18 November 2021 at 13:05:02 UTC, Steven Schveighoffer wrote:

>

Let's adjust the straw in that man:

How can you bind something global to a common identifier like i?

You are joking, right?

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

November 18

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

>

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

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.

November 18

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

>

On Wednesday, 17 November 2021 at 21:46:45 UTC, Atila Neves wrote:

>

On Tuesday, 16 November 2021 at 18:17:29 UTC, Rumbu wrote:

>

At least from my point of view, it seems that recently D made a shift from a general purpose language to a C successor,

I mean, it kind of always was, which is even indicated in the name.

I am here when D was advertised as a general purpose language. The last development efforts are concentrated around making a better C, not a better D.

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

> >

Where would you say D has failed to evolve in terms of OOP?

  • wrong idea of what private means (yes, I know that you disagree on that, but every OOP book/study/reference considers the class as unit of encapsulation);

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.

>
  • struct inheritance

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

>
  • explicit interface implementations
  • class destructuring

Could you please explain what these mean?

>
  • properties

What's missing?

>
  • pattern matching on class type

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.

>
  • pattern matching on fields/properties

How would this work?

>

Personnaly I want gc to stay and improve. But when I see the language trying its best to please the gc haters,

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 wonder if the GC is the right default memory management in D.

I believe it is, yes.

>

Finally, I found something from the old D1 page:

>

Complex Numbers
A detailed comparison with C++'s std::complex.

The most compelling reason is compatibility with C's imaginary and complex floating point >types. Next, is the ability to have imaginary floating point literals. Isn't:

c = (6 + 2i - 1 + 3i) / 3i;
far preferable than writing:

c = (complex!(double)(6,2) + complex!(double)(-1,3)) / complex!(double)(0,3);
? It's no contest.

15 years ago. I will reply with this quote to everyone who has "another library solution".

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.

November 18

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

>

On Thursday, 18 November 2021 at 13:07:28 UTC, Ola Fosheim Grøstad wrote:

>

How can you bind something global to a common identifier like i?

That's not global.

That's a rather pedantic statement.

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

November 18

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

>

On Wednesday, 17 November 2021 at 21:46:45 UTC, Atila Neves wrote:

>

The GC isn't going anywhere. It's the easiest way to write memory-safe code other than leaking everything.

What is the plan for destructors?

Objects with destructors should not be allocated on the GC-heap. Will this become a type error that is caught at compile time?

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

November 18
On Thursday, 18 November 2021 at 13:37:57 UTC, Ola Fosheim Grøstad wrote:
>> That's not global.
>
> That's a rather pedantic statement.

It is an important distinction since you get this if you want it and don't get it if you don't.
November 18

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

>

This is amazing :D

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

>

But, this has not been documented anywhere in the std.complex page, so I don't feel its fair to say that rumbu is making a straw man argument.

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

November 18

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

>

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?

[...]

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

November 18

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

>

On Wednesday, 17 November 2021 at 23:39:18 UTC, bachmeier wrote:

>

And yet they still post here. It wouldn't be so bad if they posted things that made sense. They say things like "D forces you to use the GC" which is clearly nonsense.

If you want parity with C++ language features you have to use the GC. So that is an issue.

And those feature would be...?

1 2 3 4 5 6 7 8 9 10 11 12 13 14