What are the worst parts of D?

[H. S. Teoh via Digitalmars-d]

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