December 30, 2020
On Thursday, 24 December 2020 at 08:36:54 UTC, RSY wrote:
> 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
>

Fixed with C++20 modules.

I am already playing with the experimental support on VC++.

> C++ you need to fight to get proper reflection
>

Coming in C++23, and partially available already with a mix of type traits and constexpr.


I am all good for D vs C++, but one needs to update their knowledge specially when the audience is up to date with latest ISO C++'s capabilities.

December 30, 2020
On Wednesday, 30 December 2020 at 20:42:49 UTC, jmh530 wrote:
> You mean like this
>
> struct Foo(T)
> {
>     T x;
> }
>
> void foo(T : Foo!V, V)(T x) {


Not quite, "Foo" would be a template parameter, so something like this (which does not work, but maybe there is some other way to express it?):


struct Foo(T)
{
    T x;
}


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

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




December 30, 2020
On Wednesday, 30 December 2020 at 21:12:43 UTC, Ola Fosheim Grøstad wrote:
>(which does not work, but maybe there is some other
> way to express it?):

See: https://forum.dlang.org/thread/ooxzbrmbrzpsefirosor@forum.dlang.org?page=1

December 30, 2020
On Wednesday, 30 December 2020 at 21:17:25 UTC, sighoya wrote:
> On Wednesday, 30 December 2020 at 21:12:43 UTC, Ola Fosheim Grøstad wrote:
>>(which does not work, but maybe there is some other
>> way to express it?):
>
> See: https://forum.dlang.org/thread/ooxzbrmbrzpsefirosor@forum.dlang.org?page=1

Ok, so basically just add alias:

void foo(alias T)(T!int x) {

Ok. :)


December 31, 2020
On Wednesday, 30 December 2020 at 21:03:36 UTC, Paulo Pinto wrote:
> On Thursday, 24 December 2020 at 08:36:54 UTC, RSY wrote:
>> 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
>>
>
> Fixed with C++20 modules.
>
> I am already playing with the experimental support on VC++.
>
>> C++ you need to fight to get proper reflection
>>
>
> Coming in C++23, and partially available already with a mix of type traits and constexpr.
>
>
> I am all good for D vs C++, but one needs to update their knowledge specially when the audience is up to date with latest ISO C++'s capabilities.

and you still have the predeclaration issue, since the whole process is done 1 way

and this is the summary of the whole C++ has X, but it is either half backed, or just plain bloated

you can't say c++ will have module without saying it is implemented poorly, you still have the dirty and ugly quirks

D module system remains superior because the whole experience is just plain superior and more sane

December 31, 2020
On Thursday, 31 December 2020 at 07:07:04 UTC, RSY wrote:
> On Wednesday, 30 December 2020 at 21:03:36 UTC, Paulo Pinto wrote:
>> On Thursday, 24 December 2020 at 08:36:54 UTC, RSY wrote:
>>> 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
>>>
>>
>> Fixed with C++20 modules.
>>
>> I am already playing with the experimental support on VC++.
>>
>>> C++ you need to fight to get proper reflection
>>>
>>
>> Coming in C++23, and partially available already with a mix of type traits and constexpr.
>>
>>
>> I am all good for D vs C++, but one needs to update their knowledge specially when the audience is up to date with latest ISO C++'s capabilities.
>
> and you still have the predeclaration issue, since the whole process is done 1 way
>
> and this is the summary of the whole C++ has X, but it is either half backed, or just plain bloated
>
> you can't say c++ will have module without saying it is implemented poorly, you still have the dirty and ugly quirks
>
> D module system remains superior because the whole experience is just plain superior and more sane

And you can't say C++23 will have Y therfore it is a reasonable choice TODAY

No, it's either you have it or you don't, everyone can implement Z, even Rust borrow checker, that doesn't make language 0 relevant when you compare solutions TODAY

And even more when you take into account that D is interopable with both C/C++

Invalidating D, just because X Y Z will have K and have poorly implemented N, is very unfortunate, BAD, and plain SAD, because you just don't care about what D has to offer when you take into account the whole feature set
December 31, 2020
On Wednesday, 30 December 2020 at 21:03:36 UTC, Paulo Pinto wrote:
> On Thursday, 24 December 2020 at 08:36:54 UTC, RSY wrote:
>> 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
>>
>
> Fixed with C++20 modules.
>
> I am already playing with the experimental support on VC++.
>
>> C++ you need to fight to get proper reflection
>>
>
> Coming in C++23, and partially available already with a mix of type traits and constexpr.
>
>
> I am all good for D vs C++, but one needs to update their knowledge specially when the audience is up to date with latest ISO C++'s capabilities.

It's like the story with the GC

You want everyone to like D because it has a GC despite it being not updated in ages, and proved to not scale well

You do the same with modules and reflections now, D is clearly better but for some reasons you don't want people to believe that, worse you want people to see them as inferior to the poor C++ one, because you clearly didn't mention any of that poor 1 phase compilation model

What is your goal here? you for sure don't want D to take off
December 31, 2020
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
>

Fixed with C++20 modules.


---


He said fixed with c++20 modules, when you still have to predeclare everything, as it is was a better solution

LOL, i can't believe it, bad worm



December 31, 2020
On Thursday, 31 December 2020 at 07:23:17 UTC, RSY wrote:
> 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
>>
>
> Fixed with C++20 modules.
>
>
> ---
>
>
> He said fixed with c++20 modules, when you still have to predeclare everything, as it is was a better solution
>
> LOL, i can't believe it, bad worm


```
export module app;

export int main()
{
    say_hi();
}


void say_hi()
{
    printf("hi\n");
}
```


//  error C3861: 'say_hi': identifier not found

Ohhhh it doesn't compile, it doesn't know what say_hi is, wow great c++ module system

Clearly supperior to D /s
December 31, 2020
Sorry for the spam, but this is because of people like him that people like me (i discovered D recently) that can't be aware of why D is a great language

They diminish all arguments that makes D better than alternatives


You guys have to help me fight that kind of behavior, because it doesn't help D, as if it was their goal, do they want to make sure D doesn't eat specific market share, so some other language can? fishy fishy