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