On Wednesday, 23 December 2020 at 19:00:14 UTC, evilrat wrote:
> On Wednesday, 23 December 2020 at 18:03:56 UTC, frame wrote:
>>
>> It's not the problem mentioned but I had to struggle with DLLs and D's Variant-type. The problem is that Variant uses TypeInfo which does not pass DLL boundaries correctly so that int != int in runtime even it's in fact a simple int.
>>
>> If you need to exchange unknown data between a DLL and your application you need to get a workaround and cannot use that elsewhere settled nice feature. But it's a Windows specific issue - it works as expected on other systems.
>
> Which is basically same as in C++, despite the fact it does have real working SO/DLL runtime's many large projects have their own RTTI implementation. LLVM has its own RTTI because standard type info is "inefficient", Unreal Engine has its own, IIRC Qt too has its own, etc...
>
> Same thing with D Variant, some people say it is "inefficient"... so we ended up having multiple libraries.
>
> Not saying anything about how good or bad all this, just the facts.

C++ you need to write duplicate code (.h and .cpp)

C++ you need to care about header include order

C++ you need to forward declare everything you gonna use if it is not included before

C++ you need to waste time waiting for compile

C++ you need to fight to get proper reflection


D is much more superior to C++ in my opinion, proper package manager, great compile time, great module system, great interop with C and C++

You can use GC, you can disable it, you can use malloc, it suits all your need!

Can't find a lib? use a C or C++ one, that is what makes D so much powerfull, you don't have to give up on other ecosystem, you can embrace them in your project

On Thursday, 24 December 2020 at 08:36:54 UTC, RSY wrote:
> You can use GC, you can disable it, you can use malloc, it suits all your need!

Not to forget the availability of refcounted (shared) and unique ptr too in D.

On Tuesday, 10 November 2020 at 01:00:50 UTC, Mark wrote:
> Hi all,
>
> my question would be about using D or not using D. Is the newest C++ iteration any good compared to D?
>
> [...]

https://ibb.co/syQRs9v

On Tuesday, 29 December 2020 at 16:13:50 UTC, Imperatorn wrote:
> https://ibb.co/syQRs9v

I hope I'm not the only one that thinks 'designers and std lib writers unable to name anything correctly' is kind of ironic.
And don't get me started on documentation return values.

On Wednesday, 30 December 2020 at 14:17:38 UTC, Rekel wrote:
> On Tuesday, 29 December 2020 at 16:13:50 UTC, Imperatorn wrote:
>> https://ibb.co/syQRs9v
>
> I hope I'm not the only one that thinks 'designers and std lib writers unable to name anything correctly' is kind of ironic.
> And don't get me started on documentation return values.

Most of the statements are wrong too...

"Forgot null terminator": that is C, not C++.

"undecidable grammer": wrong, not context free != undecidable

"can't execute arbitrary functions at compile time": same as D, more or less

"4732 features, but not a single one you actually want": wrong again, C++20 has features that people would like to see in D

"unsatisfying standard library": not really, unless you need to avoid exceptions

"template metaprogramming only capable of being understood by mensa member": some aspects of C++20 metaprogramming is easier than D

"multiple-inheritance hell": no idea what this means, MI is usually used for the same as D interfaces

"iterators": and ranges...

Anyway, bashing C++ does not get D anywhere. At best it makes D users look uninformed.

On Wednesday, 30 December 2020 at 14:41:28 UTC, Ola Fosheim Grøstad wrote:
> Most of the statements are wrong too...
> "4732 features, but not a single one you actually want": wrong again, C++20 has features that people would like to see in D
>
Could you elaborate a bit more, please? I'm interested.

> "unsatisfying standard library": not really, unless you need to avoid exceptions
>
> "template metaprogramming only capable of being understood by mensa member": some aspects of C++20 metaprogramming is easier than D
>
That would me interest, too!

> "multiple-inheritance hell": no idea what this means, MI is usually used for the same as D interfaces

Just to say, I think not including multiple inheritance was a mistake for Java and all its descendants, though not a big one.

Multiple inheritance needs just a good convention, that's all.

On Wednesday, 30 December 2020 at 18:24:41 UTC, sighoya wrote:
> On Wednesday, 30 December 2020 at 14:41:28 UTC, Ola Fosheim Grøstad wrote:
>> Most of the statements are wrong too...
>> "4732 features, but not a single one you actually want": wrong again, C++20 has features that people would like to see in D
>>
> Could you elaborate a bit more, please? I'm interested.

Some people in the D community has for a long time wanted stack-less coroutines. This is now available in C++20, and maybe D can borrow the C++ implementation for LDC? That is an interesting possibility for sure.

>> "template metaprogramming only capable of being understood by mensa member": some aspects of C++20 metaprogramming is easier than D
>>
> That would me interest, too!

The main addition for C++20 is concepts. Basically wrapping up ugly tests in a simple template parameter type specifier so that you can specify that a template parameter MUST support Addition or be a Stack or whatever you want to require with very simple syntax. (It also makes it easier to specify tests.)

Btw, did D ever get to add nested template parameters? I know people asked for it a long time ago, but cannot remember if that was resolved somehow?

> Just to say, I think not including multiple inheritance was a mistake for Java and all its descendants, though not a big one.
>
> Multiple inheritance needs just a good convention, that's all.

I almost never use multiple inheritance myself, but if you don't use it, it does not affect you at all? So how could it be a problem to have the option? *shrugs*

On Wednesday, 30 December 2020 at 18:45:03 UTC, Ola Fosheim Grøstad wrote:
> Some people in the D community has for a long time wanted stack-less coroutines. This is now available in C++20, and maybe D can borrow the C++ implementation for LDC? That is an interesting possibility for sure.
>

Hmm, I don't know much about them, but it seems they are a restriction to stackful coroutines, maybe a keyword addition like @stackless to prohibit nested suspension does the trick?

> The main addition for C++20 is concepts. Basically wrapping up ugly tests in a simple template parameter type specifier so that you can specify that a template parameter MUST support Addition or be a Stack or whatever you want to require with very simple syntax. (It also makes it easier to specify tests.)

In my eyes, adding proper support for opImplicitCoercion enables the reuse of interfaces as typeclasses, yielding more potential for idiomatic development than utilizing C++ concepts alone.

> Btw, did D ever get to add nested template parameters? I know people asked for it a long time ago, but cannot remember if that was resolved somehow?

Oh, what's this? Did you mean true Higher Kinded Types (HKT)

```
fun(R,S,T:R=>S)
```

That would be great, but they're simply arguing to use alias symbols instead. The downside with aliases is however a more restricted type inference:

https://github.com/dlang/DIPs/blob/bf5157d3dc29a591826e22d188448fbc04ca81b2/DIPs/DIP1023.md
https://forum.dlang.org/thread/dnyqxmgdazczwmmvayjx@forum.dlang.org?page=4


> I almost never use multiple inheritance myself, but if you don't use it, it does not affect you at all? So how could it be a problem to have the option? *shrugs*

It's right, at least theoretically, practically you are often forced to use the feature in order to utilize the functionality you need.

But the more general point against this was the clash of fields and methods. However, this is akin to the problem with generic specialization, and likewise it can be solved by simply defining a new default instance, that's it.

On Wednesday, 30 December 2020 at 19:24:19 UTC, sighoya wrote:
> In my eyes, adding proper support for opImplicitCoercion enables the reuse of interfaces as typeclasses, yielding more potential for idiomatic development than utilizing C++ concepts alone.

Not sure what you mean? A D interface is a dynamic runtime feature?


>> Btw, did D ever get to add nested template parameters? I know people asked for it a long time ago, but cannot remember if that was resolved somehow?
>
> Oh, what's this? Did you mean true Higher Kinded Types (HKT)
>
> ```
> fun(R,S,T:R=>S)
> ```


Sort of, in C++ it would be something like this

template<template<typename> class OuterName>
void myfunction(OuterName<int> x){ stuff(); }


> That would be great, but they're simply arguing to use alias symbols instead. The downside with aliases is however a more restricted type inference:

That is clearly a type unification bug. An alias isn't an alias if it interferes with type unification!

On Wednesday, 30 December 2020 at 19:51:07 UTC, Ola Fosheim Grøstad wrote:
> [snip]
>
> Sort of, in C++ it would be something like this
>
> template<template<typename> class OuterName>
> void myfunction(OuterName<int> x){ stuff(); }
>
> [snip]

You mean like this

struct Foo(T)
{
    T x;
}

void foo(T : Foo!V, V)(T x) {
    import std.stdio: writeln;
    writeln("here");
}

void main() {
    Foo!int x;
    foo(x);
}