On Tuesday, 27 February 2018 at 17:46:58 UTC, Adam D. Ruppe wrote:
> On Tuesday, 27 February 2018 at 17:41:07 UTC, H. S. Teoh wrote:
>> And just about every new dmd release, people fume on this forum about regressions and gratuitous code breakages.
>
> Not all deprecations/code breakages are *regressions* and *gratuitous*.
>
> You just need to do a cost/benefit look at it. For C++ though, supporting decades of very widespread use is doing to adjust the cost calculus of a change relative to D, of course.

+1

On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu wrote:
> https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02
>
> Andrei

D community survey is coming soon? :)

On Tuesday, February 27, 2018 17:33:52 12345swordy via Digitalmars-d wrote:
> On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu
>
> wrote:
> > https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite -2018-02
> >
> > Andrei
>
> I have submitted, already. My major complaints boils down to the fact that they refuse to deprecated features due to religious like devotions to backwards compatibility support.

The main problem with that is that the fact that as soon as you're willing to break backwards compatability in C++, then you lose one of the major benefits of C++ (that the same code compiles pretty much forever) and that if you're willing to give up on that, you might as well be using another language like D or Rust. I'm sure that there's a crowd who would love to break some aspects of backwards compatability with C++ and stick with it rather than switching to another language, but if someone actually really tried to fix C++, you wouldn't end up with C++ anymore. You might not end up with D or Rust, but it would definitely be a new language, and if you're willing to do that, why stick with C++?

The other problem is that many of C++'s problems come from being a superset of C, which is also a huge strength, and it would be a pretty huge blow to C++ if it couldn't just #include C code and use it as if it were C++. To truly fix C++ while retaining many of its strengths would require fixing C as well, and that's not happening.

- Jonathan M Davis

On Tuesday, 27 February 2018 at 20:25:32 UTC, JN wrote:
> On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu wrote:
>> https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02
>>
>> Andrei
>
> D community survey is coming soon? :)

Yes. Stay tuned.

On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis wrote:

> The other problem is that many of C++'s problems come from being a superset of C, which is also a huge strength, and it would be a pretty huge blow to C++ if it couldn't just #include C code and use it as if it were C++. To truly fix C++ while retaining many of its strengths would require fixing C as well, and that's not happening.

That's why it would be a big deal to be able to directly include C header files in D projects (as was discussed around here not that long ago).

On Tue, Feb 27, 2018 at 01:33:18PM -0700, Jonathan M Davis via Digitalmars-d wrote: [...]
> The main problem with that is that the fact that as soon as you're willing to break backwards compatability in C++, then you lose one of the major benefits of C++ (that the same code compiles pretty much forever)

Not strictly true.  My old C++98 project no longer compiled with the latest g++, because it contained things allowed in C++98 that are no longer allowed in C++17.  Some things were relatively simple to fix, but others were quite painful to fix, so I ended up using --std=c++11 as a workaround instead.  In the frustrating process of trying to fix things C++17 complains about, I threw in the towel and decided to rewrite it in D instead.


[...]
> The other problem is that many of C++'s problems come from being a superset of C, which is also a huge strength, and it would be a pretty huge blow to C++ if it couldn't just #include C code and use it as if it were C++.

Not strictly true either.  Most modern C header files come wrapped with:

	#ifdef __cplusplus
	extern "C" {
	#endif

	...

	#ifdef __cplusplus
	}
	#endif __cplusplus

because without that, a lot of C headers actually would *not* compile.

Granted, though, this is a lot easier than having to write JNI wrappers or (carefully!) translate C headers into D.  It would be nice if you could actually just copy-n-paste a C header into an extern(C) block in D and have it Just Work(tm), but practically all C headers are dependent on macros one way or another that it would require including an entire C processor inside the D compiler, which is not exactly an inviting proposition.


> To truly fix C++ while retaining many of its strengths would require fixing C as well, and that's not happening.
[...]

Actually, C and C++ have already somewhat diverged. The C subset of C++ is an actually older dialect of C, and no longer 100% compatible with modern C.  Though it's true that it's still 95% compatible, which is Good Enough(tm) for most purposes.


T

-- 
A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived. -- Michael B. Allen

On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote:

> Granted, though, this is a lot easier than having to write JNI wrappers or (carefully!) translate C headers into D.  It would be nice if you could actually just copy-n-paste a C header into an extern(C) block in D and have it Just Work(tm), but practically all C headers are dependent on macros one way or another that it would require including an entire C processor inside the D compiler, which is not exactly an inviting proposition.

Walter has said that he has considered doing that now that DMC is Boost licensed:
https://forum.dlang.org/post/p58q2l$1d35$1@digitalmars.com

On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis wrote:
> On Tuesday, February 27, 2018 17:33:52 12345swordy via Digitalmars-d wrote:
>> On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu
>>
>> wrote:
>> > https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite -2018-02
>> >
>> > Andrei
>>
>> I have submitted, already. My major complaints boils down to the fact that they refuse to deprecated features due to religious like devotions to backwards compatibility support.
>
> The main problem with that is that the fact that as soon as you're willing to break backwards compatability in C++, then you lose one of the major benefits of C++ (that the same code compiles pretty much forever) and that if you're willing to give up on that, you might as well be using another language like D or Rust. I'm sure that there's a crowd who would love to break some aspects of backwards compatability with C++ and stick with it rather than switching to another language, but if someone actually really tried to fix C++, you wouldn't end up with C++ anymore. You might not end up with D or Rust, but it would definitely be a new language, and if you're willing to do that, why stick with C++?
>
> The other problem is that many of C++'s problems come from being a superset of C, which is also a huge strength, and it would be a pretty huge blow to C++ if it couldn't just #include C code and use it as if it were C++. To truly fix C++ while retaining many of its strengths would require fixing C as well, and that's not happening.
>
> - Jonathan M Davis

Yes I know that backwards compatibility comes with benefits, but gosh darn it, it doesn't stop me from complaining about it. Even more so it's very popular language to develop video games on it.

On Tue, Feb 27, 2018 at 09:44:45PM +0000, bachmeier via Digitalmars-d wrote:
> On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote:
> 
> > Granted, though, this is a lot easier than having to write JNI wrappers or (carefully!) translate C headers into D.  It would be nice if you could actually just copy-n-paste a C header into an extern(C) block in D and have it Just Work(tm), but practically all C headers are dependent on macros one way or another that it would require including an entire C processor inside the D compiler, which is not exactly an inviting proposition.
> 
> Walter has said that he has considered doing that now that DMC is Boost licensed: https://forum.dlang.org/post/p58q2l$1d35$1@digitalmars.com

Wouldn't that cause compatibility issues with gdc/ldc?


T

-- 
Give me some fresh salted fish, please.

On Tuesday, February 27, 2018 15:28:21 H. S. Teoh via Digitalmars-d wrote:
> On Tue, Feb 27, 2018 at 09:44:45PM +0000, bachmeier via Digitalmars-d
wrote:
> > On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote:
> > > Granted, though, this is a lot easier than having to write JNI wrappers or (carefully!) translate C headers into D.  It would be nice if you could actually just copy-n-paste a C header into an extern(C) block in D and have it Just Work(tm), but practically all C headers are dependent on macros one way or another that it would require including an entire C processor inside the D compiler, which is not exactly an inviting proposition.
> >
> > Walter has said that he has considered doing that now that DMC is Boost licensed: https://forum.dlang.org/post/p58q2l$1d35$1@digitalmars.com
>
> Wouldn't that cause compatibility issues with gdc/ldc?

It wouldn't if the idea were to move parts of dmc into the frontend, and _something_ would have to be put in the frontend for such a thing, even if it meant accessing the C/C++ compiler via library rather than adding the C/C++ stuff into the frontend itself. But I don't know what Walter is thinking exactly.

- Jonathan M Davis