On 08/14/2016 01:18 AM, Shachar Shemesh wrote:
On 14/08/16 03:26, Andrei Alexandrescu wrote:
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?
http://www.digitalmars.com/d/archives/digitalmars/D/What_is_going_on_here_257862.html
OK. One thing we can't stress enough is that everything - talks, slides,
newsgroup posts - about a bug in the language definition or
implementation must be in support of an issue. No issue no honey. I
submitted https://issues.dlang.org/show_bug.cgi?id=16388 on your behalf
and preapproved it. Please carry future considerations there.
I'm quite fine with disagreeing on this point, but I do want to make
sure we agree on what it is we disagree about.
My view of the C++ const situation is consistent with C++'s philosophy
about pretty much everything, which is this. "We give you very powerful
tools to do many things. We do not, however, prevent you from misusing
them. Caveat emptor".
C++'s "logical constness" may lead to pretty twisted stuff if misused,
but the flip side is that, when used correctly, it can be used quite
extensively to give the compiler tools to protect you from mistakes.
D's const, to me (please correct me if I'm wrong), aimed not at helping
the compiler help the programmer, but at helping the compiler. It
contains a much stronger guarantee, and accordingly, is applicable in
much fewer cases.
It is my understanding that we agree on the above. If we do, I can state
my opinion, and you are most welcome to disagree with it, and we can
call that matter resolved.
In my experience, D's guarantee is too strong, in that it is too often
inapplicable. This leads to two bad things happening.
The first is that you can rarely put "const" on anything, meaning you
lose the power that C++'s guarantee gave you, and not gain enough in
return.
The second is that, since it is so rarely applicable, people tend to
forget implementing the const version of methods, even when those are
easy. This leads to a situation where, even if const can be applied, it
is just too much work to weed out the bugs all over the place this will
cause, and people give up.
Compound this with the total mess that is "inout", and I, personally,
just gave up. I know I'm not the only one.
I understand. One thing we want to do to improve on that is to deduce
const for template methods. See
https://issues.dlang.org/show_bug.cgi?id=16389.
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.
I will. I just don't know how long it will take me to get to it. I
already tried to recreate it simply with two structs and just the
relevant ops, without success (though, now that I think of it, it might
have been with a different version than the one that compiles our code).
If you want, since I know you have access, I can send you the line
number from which this was taken.
Either way, this is just one example out of many where the interaction
between features creates complex situations that either result in not
defined (as opposed to undefined) behavior, or result in behavior that
may be well defined, but is surprising to the programmer.
This being a matter of perception, there's no disagreement here. To turn
this into something actionable it would be great if you thought of ways
to simplify said interaction without breaking code (e.g. by removing
unnecessary constraints).
- 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.
Won't solve my problems unless VRP's scope is significantly enhanced.
Your book said VRP is only defined to work on the same expression it is
in. So long as that's the case, it's not a matter of fixing bugs.
It's a matter of school of thought. C and C++ allow implicit casts that
lose information. C# and Java do not. Each has pluses and minuses. D is
on the C# and Java side, with VRP which reduces the number of explicit
casts needed. Here again we're not talking about a bug in the language
or the "right" or "wrong" language design, it's just a matter in which
different languages do different things.
Also, I should point out, that I'm not suggesting D allow implicit
narrowing conversions. Instead, I think D should drop the pretense that
C expressions should maintain their semantics precisely, and stop
widening expressions.
This will not happen.
I must confess that I have never heard of this rule in C before
encountering it in D.
Which rule?
Any time I needed some expression to take place
with a width larger than the input arguments, I always casted them.
So then why do you complain D asks for "too many" casts?
Since this is still necessary for long, I think dropping this rule won't
be too big of an issue.
You kind of lost me there. So which rule?
- No ref type.
This you need to live with.
Can you expand a little on the rational for that?
The "ref" attribute has been a fundamental part of the language for too
long.
Also, part of our
problems with this is that introspection also does not see refs, which
causes the following two functions to report the same signature:
void func1(int arg);
void func2(ref int arg);
I actually think you can do introspection on any argument to figure
whether it has "ref".
We'd love to make the life easier for Weka,
I'd like to make it clear here that I speak of my own experience. I do
talk with people, and some of the engineers share some of my criticism.
However, please don't think that just because I'm more vocal than others
in Weka, it means that my opinions are shared by all. Please treat my
posts here as my own.
There are some good points that we could easily agree need to be
improved. At some point you must get in gear and submit some issues to
move forward on things important to Weka.
From what I understand, there is a problem with the way imports are put
in the di files. In particular, take the following code:
import some.struct: SomeStruct;
import some.other.struct: SomeOtherStruct;
SomeStruct func() {
SomeOtherStruct a(3);
return a.some;
}
The ideal di for it would be:
import some.struct: SomeStruct;
SomeStruct func();
Sadly, the actual di also contains the totally unnecessary:
import some.other.struct: SomeOtherStruct;
The result is that the di contains too many imports, and no gains are
made vis compilation times.
I think you forgot to mention the issue number :o).
Andrei
