On 28-04-2012 23:41, Timon Gehr wrote:
On 04/28/2012 11:05 PM, q66 wrote:
On Saturday, 28 April 2012 at 20:50:30 UTC, H. S. Teoh wrote:
On Sat, Apr 28, 2012 at 09:22:59PM +0200, q66 wrote:
[...]
- AAs integrated in the language; you barely ever use AA literals and
having them purely in Phobos would help get rid of the runtime fat, as
well as better implementations
On the contrary, AA's are a major reason I started programming in D. In
this day and age, it's simply inexcusable to *not* have some kind of
hash type available by default.
Besides AA literals, library can handle this JUST FINE.
That is why they should be a narrow wrapper around a library defined type.
- Phobos is too fat - it needs to shrink to just a few core modules,
others being distributed via some system like CPAN for Perl
Um... that's what a *library* is supposed to be: a large collection of
useful stuff from which you can pick the few that you need right now.
Too large collection becomes too hard to manage. Separating it and
distributing in style "you pay for what you use" is IMO the right
approach.
This sounds reasonable.
- Properties - they're kinda broken at this point and the value is
questionable
What kind of properties are you referring to?
The @property crap. It's broken. If anything, it needs something like in
C#.
As I understand it, the 'agreed upon' design is that
@property int foo() { return x; }
@property void foo(int v) { x = v; }
Would be completely equivalent to C#:
int foo { set{ x = value; }; get{ return x; } }
Nope.
First of all, you'd have to declare the setter like this in D:
@property int foo(int v) { return x = v; }
so that you can write:
int v = obj.foo = 1; // valid C#
Next up is the issue of op-assign operations. In D, you can't do:
obj.foo += 1;
obj.foo++;
while in C#, you can (it results in a get -> add 1 -> set and get -> inc
-> set, etc).
I think it is even perfectly fine to just allow function calls without
parentheses, but I wouldn't mind seeing that feature gone.
- @trusted @system
These are necessary.
They're far from necessary.
Why? Memory safety is generally considered to be important.
- Exception handling - a lot of runtime, questionable value
I completely disagree. No exception handling means lots and lots and
lots of boilerplate code for checking error codes, return values, which
are too tedious to write, which translates to many people leaving them
out and ending up with unreliable code that fail silently or crash
outright when a function call they assumed would work stopped working.
If you've worked in large multi-person projects, you'll see very quickly
why you *need* exception handling. No modern language can do without
exception handling. Maybe you have a beef with how it's currently done
in D, but regardless, you *need* exception handling of some kind.
The exception handling system via try/catch is as bad and tedious as
error codes, except the added runtime.
It can improve performance though, because the exceptional branches
don't occur in the code that is normally executed.
It all roots from the idea "catch everything that throws".
This is broken, as you DON'T always need to
handle all sorts of errors (letting it segfault or something sometimes
simply proves to be better than trying to save the situation;
Except that it won't necessarily segfault.
That is not how _reliable_ systems work. Robustness is an important
property of critical systems. If your software might kill people if it
behaves in the wrong way, you really really don't want to ignore error
conditions.
or you can simply assert it).
Certainly, if it is a consistency criterion internal to the program,
then assertions should be used.
Also http://yosefk.com/c++fqa/exceptions.html#fqa-17.1
[snip.]
The part of this article relevant for D is this:
"Still, in many cases, the benefits of exceptions are more important
than their problems. For example, if your language manages memory
automatically, the problem of releasing acquired resources becomes a
small one (you only have to care about files, etc., which are a tiny
part of the "resources" used by a program - most of the "resources" are
memory). If your language throws exceptions when you violate its rules
(for example, upon out-of-bounds array access), these exceptions will
help you find lots of bugs, especially if you can get the call stack
from an exception. If the purpose of an application is automated
testing, and/or it's used as a quick-and-dirty internal tool as opposed
to a product for an end user, this kind of exceptions is all you need to
handle errors of almost all kinds. In some languages, you can even
resume the execution from the point where the exception was raised after
fixing the problem at the point where it was caught."
Anyway, I generally avoid exceptions if they are not an obvious fit.
--
- Alex
