On 08/13/2016 05:57 PM, Jonathan M Davis via Digitalmars-d wrote:
I'm also tempted to argue that making shared virtually unusable without
casting it away would be a good idea
It's a bad idea, no two ways about it. The bummer here is that this is
the only topic (and one where D gets it right) off of a whole list that
Shachar gave, which I'll copy below. His slides are at
http://www.slideshare.net/ShacharShemesh1/dconf-2016-d-improvement-opportunities.
Is the talk video anywhere?
- No RAII support, despite the fact everybody here seems to think that D
supports RAII.
So that is slide 4. Could you please give a bit of detail?
- Recursive const makes many cases where I can use const in C++ (and
enjoy the protection it provides) simply mutable in D.
(It's transitive, not recursive.) Can't help much here but note that
C++'s const being shallow is a source of confusion among beginning
programmers. It's a matter in which reasonable people may disagree. I
clearly see how someone used to C++'s const wold feel uncomfortable with
D's.
- This one I have not complained about yet. Operator overloads
stepping on each other's toes. In my case, I have a container (with
opIndex that accepts a custom type and opOpAssign!"~") and I place in
it a struct with some operator overloads as well (have not reduced
the cause yet, hence no previous complaint about this one). So, when
I write
Container[IndexType] ~= Type;
And the compiler assumes that means:
Container.opIndexOpAssign!"~"(IndexType, Type);
but since nothing like that is defined, the code doesn't compile. I
ended up writing (actual code from the Weka code base):
blockIds[diskIdx].opOpAssign!"~"(makeBlockId(stripeIdx+i,
placement.to!SlotIdx(diskIdx)));
Took me almost ten minutes and consulting someone else to find this
solution.
The opIndexOpAssign family is intentional and arguably a good thing. The
semantics of std::map's operator[] are controversial and suboptimal;
opIndexOpAssign is specially designed to allow efficient dictionaries
and sparse arrays. If you get to reduce the code we'd definitely want to
fix whatever bug is there.
- GC. GC. GC. Some more GC.
You mean there's too much of it? We're on that.
- Integral type operations promotion and the constant need for casts.
This is... funny coming from a self-proclaimed C++ lover. Anyhow, VRP
has bugs that we need to fix.
- No warning for signed/unsigned comparisons. An unfailing source for bugs.
This is actionable too.
- No ref type.
This you need to live with.
We'd love to make the life easier for Weka, but you need to be careful
when mixing things of the D ethos you don't like but won't change
(qualifiers, ref) with things that we can improve.
Did you try the .d/.di compile-time table?
Andrei
