On Tuesday, 23 September 2014 at 19:10:07 UTC, H. S. Teoh via Digitalmars-d wrote:
> On Tue, Sep 23, 2014 at 07:01:05PM +0000, Sean Kelly via Digitalmars-d wrote:
>> On Tuesday, 23 September 2014 at 18:38:08 UTC, Andrei Alexandrescu wrote:
>> >
>> >Well put. Again, the two things we need to work on are C++
>> >compatibility and the GC. -- Andrei
>> 
>> Has much thought gone into how we'll address C++ const?
>
> Is that even addressable?? D const is fundamentally different from C++
> const. Short of introducing logical const into D, I don't see how we
> could bridge the gap.

I haven't really thought about it, but something could probably be made to work with type wrappers that do implicit casting plus just pretending that const is the same like we do with our C interfaces.  I'm also wondering how we'd handle something like:

struct S { virtual int foo() {...} };
std::map<int,S> m;

We'd have to make S a value type in D, so struct, but D struct does't allow virtual functions.  Maybe something weird with in-place construction of classes?  I suspect the more we look into C++ compatibility the more problems we'll find, and actually interfacing with most C++ code worth using will result in terrifying D code.  But I hope I'm wrong since C++ support is apparently now where all of our effort is being devoted (mark me down as being completely uninterested in this feature despite using C/C++ at work).

On Tue, Sep 23, 2014 at 07:50:38PM +0000, Sean Kelly via Digitalmars-d wrote:
> On Tuesday, 23 September 2014 at 19:10:07 UTC, H. S. Teoh via Digitalmars-d wrote:
> >On Tue, Sep 23, 2014 at 07:01:05PM +0000, Sean Kelly via Digitalmars-d wrote:
[...]
> >>Has much thought gone into how we'll address C++ const?
> >
> >Is that even addressable?? D const is fundamentally different from C++ const. Short of introducing logical const into D, I don't see how we could bridge the gap.
> 
> I haven't really thought about it, but something could probably be made to work with type wrappers that do implicit casting plus just pretending that const is the same like we do with our C interfaces. I'm also wondering how we'd handle something like:
> 
> struct S { virtual int foo() {...} };
> std::map<int,S> m;
> 
> We'd have to make S a value type in D, so struct, but D struct does't allow virtual functions.  Maybe something weird with in-place construction of classes?

Or turn them into function pointers / member delegates? But that doesn't work well with ABI compatibility.


> I suspect the more we look into C++ compatibility the more problems we'll find,

SFINAE is another dark corner of disaster waiting to happen, once we decide to implement C++ template compatibility. As well as Koenig lookup, which will become indispensible if D code is to actually use non-trivial C++ libraries.


> and actually interfacing with most C++ code worth using will result in terrifying D code.  But I hope I'm wrong since C++ support is apparently now where all of our effort is being devoted (mark me down as being completely uninterested in this feature despite using C/C++ at work).

Yeah, I can't say I'm exactly thrilled about being able to call C++ code from D. I suppose it's a nice-to-have, but I'm not sure how well that's gonna work in practice, given the fundamental differences between D and C++.

But be that as it may, if we're serious about cross-linguistic ABI compatibility, then we better start with a solid design of how exactly said interfacing is going to happen in a way that fits in well with how D works. Cowboying our way through piecemeal (i.e., ad hoc addition of compatibilities like adding C++ class support, then C++ templates, then SFINAE in extern(c++), then ...) isn't going to cut it. We might end up reinventing C++, even more poorly than C++ already is.


T

-- 
Everybody talks about it, but nobody does anything about it!  -- Mark Twain

On Tuesday, 23 September 2014 at 20:22:32 UTC, H. S. Teoh via
Digitalmars-d wrote:
> SFINAE is another dark corner of disaster waiting to happen, once we
> decide to implement C++ template compatibility. As well as Koenig
> lookup, which will become indispensible if D code is to actually use
> non-trivial C++ libraries.
>

We don't need these to be compatible with C++. We don't want to
be able to cut/paste C++ into a . file and expect it to compile,
but that you can map a reasonable amount of C++ constructs and
expect them to interact with the C++ code and back.

On 9/23/14, 4:25 PM, deadalnix wrote:
> On Tuesday, 23 September 2014 at 20:22:32 UTC, H. S. Teoh via
> Digitalmars-d wrote:
>> SFINAE is another dark corner of disaster waiting to happen, once we
>> decide to implement C++ template compatibility. As well as Koenig
>> lookup, which will become indispensible if D code is to actually use
>> non-trivial C++ libraries.
>>
>
> We don't need these to be compatible with C++. We don't want to
> be able to cut/paste C++ into a . file and expect it to compile,
> but that you can map a reasonable amount of C++ constructs and
> expect them to interact with the C++ code and back.

Yah, that's exactly it. Syntax and semantics stay D; the functions called may be C++. -- Andrei

On Tue, Sep 23, 2014 at 11:25:52PM +0000, deadalnix via Digitalmars-d wrote:
> On Tuesday, 23 September 2014 at 20:22:32 UTC, H. S. Teoh via Digitalmars-d wrote:
> >SFINAE is another dark corner of disaster waiting to happen, once we decide to implement C++ template compatibility. As well as Koenig lookup, which will become indispensible if D code is to actually use non-trivial C++ libraries.
> >
> 
> We don't need these to be compatible with C++. We don't want to be able to cut/paste C++ into a . file and expect it to compile, but that you can map a reasonable amount of C++ constructs and expect them to interact with the C++ code and back.

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.

As for Koenig lookup, you might run into problems if you declare C++ wrappers for D functions in the C++ part of the codebase, and suddenly the wrong D functions are getting called due to Koenig lookup in C++ which wasn't considered when the D part of the code was written.


T

-- 
Без труда не выловишь и рыбку из пруда.

On 9/23/14, 5:06 PM, H. S. Teoh via Digitalmars-d wrote:
> You *will* need SFINAE if you expect to interface C++ template libraries
> with D.

Nope. -- Andrei

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

I think you can support a large part of C++ template without SFINAE. It is not that common and only matter for the binding if it changes the interface or the layout of something.

If one want to map these, it can be done with some static if magic. But I'm fairly confident that it won't even be necessary is most situations.

On 9/23/2014 7:29 AM, Sean Kelly wrote:
> The lack of clear direction or communication thereof.  A continual adding of new
> stuff to try and appease the theoretical masses who will certainly come flocking
> to D if implemented, and a lack of attention paid to tightening up what we've
> already got and deprecating old stuff that no one wants any more.

I find this hard to reconcile with what the changelog says.

> And inconsistency in how things work in the language.  Oh, and function attributes.
> I'm sure someone likes them, but I'm drowning in pure system const immutable
> @nogc @illegitemate @wtf hell.

Fortunately, those attributes are inferred for template functions.

I did try to extend that to auto functions, but got a lot of resistance.

On 9/21/2014 3:16 PM, H. S. Teoh via Digitalmars-d wrote:
> On Sun, Sep 21, 2014 at 08:49:38AM +0000, via Digitalmars-d wrote:
>> On Sunday, 21 September 2014 at 00:07:36 UTC, Vladimir Panteleev wrote:
>>> On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
>>>> What do you think are the worst parts of D?
>>>
>>> The regressions!
>>>
>>> https://issues.dlang.org/buglist.cgi?bug_severity=regression&list_id=106988&resolution=---
>>>
>>> I filed over half of those...
>>
>> I guess you found them using your own code base? Maybe it would make
>> sense to add one or more larger projects to the autotester, in
>> addition to the unit tests. They don't necessarily need to be
>> blocking, just a notice "hey, your PR broke this and that project"
>> would surely be helpful to detect the breakages early on.
>
> This has been suggested before. The problem is resources. If you're
> willing to donate equipment for running these tests, it would be greatly
> appreciated, I believe.

No, that's not the problem. The problem is what to do when the "larger project" fails.

Currently, it is the submitter's job to adjust the test suite, fix phobos code, whatever is necessary to get the suite running again. Sometimes, in the more convoluted Phobos code, this can be a real challenge.

Now replace that with somewhere in a large project, which our poor submitter knows absolutely nothing about, it fails. You're asking him to go in, understand this large project, determine if it's a problem with his submission or a problem with the large project, and fix it.

At some level, then WE become the maintainers of that large project.

This is completely unworkable.

On 9/22/2014 10:16 AM, luminousone wrote:
> What is needed?

The people who maintain large projects need to try them out with the beta compilers and file any regressions.