On 9/24/2014 3:00 AM, Vladimir Panteleev wrote:
> Nevertheless, this is not enough. It must be automatic - it must verify the
> state of things daily, without human intervention. It's unreasonable (borderline
> absurd, even) to expect that every large project maintainer to manually verify
> if their project still works every day.
>
> It doesn't need to run on the same hardware as the autotester. It can run on the
> project maintainers' servers or home computers. But it must be easy to set up,
> and it should notify both the project owners and the pull request authors.

If it is something opted in or out by the project maintainers, and is not part of the autotester, and runs on the project maintainer's system, I'm for it.

On Wednesday, 24 September 2014 at 09:57:06 UTC, ketmar via Digitalmars-d wrote:
> On Wed, 24 Sep 2014 09:15:27 +0000
> Paulo  Pinto via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> Most of us cannot afford to be a "Technology X" developer.
>> Every project, every client is a complete new world.
> yeah. and so there is *no* *reason* to stress c++ interop, heh. 'cause
> "client dictates language" anyway. i like it.

I do understand your concerns and I once mentioned in a thread that companies who use D should not dictate the way D evolves, instead it should remain community driven. Say for example D were used on web servers and a huge amount of effort was directed towards turning D into a web server language, while other important features/improvements were neglected, that'd be bad.

However, in the case of C++ I must say that it is important. One of the reasons I opted for D was (and still is) its seamless C-integration. It allowed me to use so much existing code in C, libraries I would and could never have rewritten myself in D. There are loads of C(++) libraries out there you might want to or have to use for a particular project. When I started using D the Unicode module lacked certain features I needed. I just used an existing C library and could go on with the real program in D. Hadn't this been possible, the project in D would have died right then and there. Now D itself has the features I needed back then, but the C library was essential to bridge the gap. I think a lot of C++ programmers would do the same. Start a new project in D resting assured they can still use their carefully built code bases in C++. So I think interop with C++ is important. And don't forget that the reality is that most people interested in (yet reluctant about) D are C++ programmers, at least that's the impression I get here.

On Wednesday, 24 September 2014 at 06:29:20 UTC, Walter Bright wrote:
> https://github.com/D-Programming-Language/dmd/pull/4021

That can be a good case to start with dfix. Its first task can be rewrite of C-style declarations to D-style.

On Wednesday, 24 September 2014 at 06:54:38 UTC, Walter Bright wrote:
>
> If users have a "must have" C++ library, they can hook up to it. Can they use other languages? Nope. They have to wrap it with a C interface, or give up. Wrapping with a C interface tends to fall apart when any C++ templates are involved.

That's exactly the case for the company I work for.
---
/Paolo

On Wednesday, 24 September 2014 at 00:08:19 UTC, H. S. Teoh via Digitalmars-d wrote:
> You *will* need SFINAE if you expect to interface C++ template libraries
> with D. Imagine that an existing codebase is using some C++ template
> library that depends on SFINAE. You'd like to start migrating to D, so
> you start writing new code in D. Eventually you need to make use of the
> C++ template library in order to interface with the C++ parts of the
> code, so you write a .di that declares template functions in an
> extern(c++) block. It works...  some of the time. Other times you start
> getting weird errors or the wrong functions get called, because the C++
> template library was written with SFINAE in mind, but D doesn't have
> that. So at the end of the day, it's a gigantic mess, and you go
> crawling back to C++.
>
> Unless, of course, we draw the line at templates and say that we won't
> support template compatibility with C++ (and I'd fully support that
> decision!). But that means we throw all C++ template libraries out the
> window, and any C++ codebase that makes heavy use of a template library
> will have to be rewritten from scratch in D.

I'm not a C++ guru, but it looks like SFINAE exists for simplicity, so that templates can be matched without template constraints and reflection. This looks equivalent to D template constraints. If template doesn't work for some parameters, just filter them out.

On Wednesday, 24 September 2014 at 10:02:20 UTC, ketmar via Digitalmars-d wrote:
> On Wed, 24 Sep 2014 09:28:25 +0000
> no sane management (and insane too, even more) will resist to adding
> new language to codebase without really strong arguments.

This is starting to be a little offensive...
---
/Paolo

On 9/24/14, 1:08 AM, ketmar via Digitalmars-d wrote:
> On Wed, 24 Sep 2014 07:59:40 +0000
> Meta via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> You forget that D is now actively used at Facebook
> no, i'm not. i just can't see why facebook priorities should be D
> priorities. facebook needs c++ interop? ok, they can hire alot of
> programmers to write this. *not* Walter and Andrei. and not dragging
> that into primary targets for D.

Your guidance of my career is uncalled for.

>> not even really a question of whether C++ support should be
>> worked on or not, in my opinion.
> i'm not against c++ interop, i'm just against making it high-priority
> task. it's not something that we *must* have, it's just a "good-to-have
> feature", nothing more.

This is Walter's and my vision. He is working on C++ interop, and I am working on C++ interop. To the extent possible we hope the larger community will share this vision and help us to implement it.


Andrei

On Wednesday, 24 September 2014 at 11:20:24 UTC, Kagamin wrote:
> On Wednesday, 24 September 2014 at 06:29:20 UTC, Walter Bright wrote:
>> https://github.com/D-Programming-Language/dmd/pull/4021
>
> That can be a good case to start with dfix. Its first task can be rewrite of C-style declarations to D-style.

+1

On Wednesday, 24 September 2014 at 07:43:49 UTC, Walter Bright wrote:
> On 9/23/2014 11:28 PM, Manu via Digitalmars-d wrote:
>> 1. Constant rejection of improvements because "OMG breaking change!".
>> Meanwhile, D has been breaking my code on practically every release
>> for years. I don't get this, reject changes that are deliberately
>> breaking changes which would make significant improvements, but allow
>> breaking changes anyway because they are bug fixes? If the release
>> breaks code, then accept that fact and make some real proper breaking
>> changes that make D substantially better! It is my opinion that D
>> adopters don't adopt D because it's perfect just how it is and they
>> don't want it to improve with time, they adopt D *because they want it
>> to improve with time*! That implies an acceptance (even a welcoming)
>> of breaking changes.

I agree completely. I would say that the #1 problem in D is the paranoid fear of breaking backwards compatibility. I said that in my 2013 talk. It is still true today.

Sociomantic says, PLEASE BREAK OUR CODE! Get rid of the old design bugs while we still can.

For example: We agreed *years* ago to remove the NCEG operators. Why haven't they been removed yet?

As I said earlier in the year, one of the biggest ever breaking changes was the fix for array stomping, but it wasn't even recognized as a breaking change!
Breaking changes happen all the time, and the ones that break noisily are really not a problem.

"Most D code is yet to be written."

> What change in particular?

I've got a nasty feeling that you misread what he wrote. Every time we say, "breaking changes are good", you seem to hear "breaking changes are bad"!

The existing D corporate users are still sympathetic to breaking changes. We are giving the language an extraordinary opportunity. And it's incredibly frustrating to watch that opportunity being wasted due to paranoia.

We are holding the door open. But we can't hold it open forever, the more corporate users we get, the harder it becomes.
Break our code TODAY.

"Most D code is yet to be written."

On 9/24/14, 6:06 AM, Kagamin wrote:
> I'm not a C++ guru, but it looks like SFINAE exists for simplicity, so
> that templates can be matched without template constraints and
> reflection. This looks equivalent to D template constraints. If template
> doesn't work for some parameters, just filter them out.

That's right. The enable_if etc. stuff is still part of the type (and therefore the mangling), but the selection itself can be trivially done on the D side with template constraints. No worries, we know how to do it. -- Andrei