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.

I've never complained about not being able to use Phobos, as I've always viewed Phobos as being too much of a high level scripting-oriented library.

I wasn't putting you in the group that makes crazy claims about the GC.

November 18

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.

>

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);
  • struct inheritance
  • explicit interface implementations
  • class destructuring
  • properties
  • pattern matching on class type
  • pattern matching on fields/properties
  • implicit constructors
> >

Now, without a gc, more than half of the language risks to become unusable and that's why I ask myself how do you see the future of the memory management in D?

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

Personnaly I want gc to stay and improve. But when I see the language trying its best to please the gc haters, I wonder if the GC is the right default memory management in D. That was in fact the main idea of this post, which model of memory management will be more suitable to be assumed in D to make everyone happy.

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".

November 18
On Thursday, 18 November 2021 at 04:24:56 UTC, rumbu wrote:
>
> Personnaly I want gc to stay and improve. But when I see the language trying its best to please the gc haters, I wonder if the GC is the right default memory management in D. That was in fact the main idea of this post, which model of memory management will be more suitable to be assumed in D to make everyone happy.

You want to make everyone happy? Good luck with that ;-)

In any case....

"People often think that D is a garbage collected language. I hope to disabuse them of that notion.."

https://www.youtube.com/watch?v=_PB6Hdi4R7M

November 18
On Thursday, 18 November 2021 at 05:50:22 UTC, forkit wrote:
> On Thursday, 18 November 2021 at 04:24:56 UTC, rumbu wrote:
>>
>> Personnaly I want gc to stay and improve. But when I see the language trying its best to please the gc haters, I wonder if the GC is the right default memory management in D. That was in fact the main idea of this post, which model of memory management will be more suitable to be assumed in D to make everyone happy.
>
> You want to make everyone happy? Good luck with that ;-)
>
> In any case....
>
> "People often think that D is a garbage collected language. I hope to disabuse them of that notion.."
>
> https://www.youtube.com/watch?v=_PB6Hdi4R7M

Lol. Look, C# is not a garbage collected language:

int* x = stackalloc int[100];
int* y = Marshal.AllocHGlobal(1000);
struct RC<T> where T: struct { ... }

O course, metaprogramming makes things easier in D, but pretending that D is not a garbage collected language when you cannot join two arrays or throw an exception without digging  outside the language for a replacement is absurd.



November 18

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

>
  • struct inheritance
  • explicit interface implementations
  • class destructuring
  • properties
  • pattern matching on class type
  • pattern matching on fields/properties
  • implicit constructors

What is "class destructuring"?

I would add user-provided default constructors to this list.

>

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".

C++ can do this in a library:

https://en.cppreference.com/w/cpp/language/user_literal

You need to find a better example. :-)

November 18

On Thursday, 18 November 2021 at 11:08:17 UTC, Ola Fosheim Grøstad wrote:

>

What is "class destructuring"?

In D idioms allowing to overload tupleof if it was an operator. Combined with tuple support you can have the following code:

class A { int x; int y}
A a = new A();
(int v, int w) = a; // v will contain a.x, w will contain a.y

> >

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

C++ can do this in a library:

https://en.cppreference.com/w/cpp/language/user_literal

You need to find a better example. :-)

This was to show how D paradigm shifted in 15 years from avoiding library solutions to encouraging them.

November 18

On Thursday, 18 November 2021 at 12:42:04 UTC, Rumbu wrote:

>

In D idioms allowing to overload tupleof if it was an operator.

Ok, I get it. So that would work with public fields only?

Yes, it is a weakness that class/struct are different yet very similar. Ideally a tuple should be syntactic sugar for a struct.

>

This was to show how D paradigm shifted in 15 years from avoiding library solutions to encouraging them.

Yes. Andrei did that with D2. A strategic mistake, but perhaps more fun.

November 18

On 11/17/21 11:24 PM, rumbu wrote:

>

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".

Let's adjust the straw in that man:

import std.complex;

auto i(double v)
{
    return complex(0, v);
}

void main()
{
    auto c = (6 + 2.i - 1 + 3.i) / 3.i;
}

-Steve

November 18

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?

November 18

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

>

On 11/17/21 11:24 PM, rumbu wrote:

>

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".

Let's adjust the straw in that man:

import std.complex;

auto i(double v)
{
    return complex(0, v);
}

void main()
{
    auto c = (6 + 2.i - 1 + 3.i) / 3.i;
}

-Steve

This is amazing :D

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.

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