Michiel Helvensteijn wrote:
Aren't immutable and enum the same thing? At least to the programmer?
Not at all. How would you declare a type that is "pointer to immutable
int" using an enum? Anyhow, there was a looong thread about this a year
back or so.
* Contract programming (no contract inheritance, no compile-time static
analysis, no loop invariants / ranking functions)
True, but compile-time static analysis is a "quality of implementation"
issue.
Only when you're talking about optimization. There is great value in
automatic proof of correctness. But I know this is a tall order.
Furthermore, I know of no language other than Eiffel that has all
this, and nobody uses Eiffel.
That's a spurious argument. The reason people don't use Eiffel is not its
advanced contract programming features. (It may be the syntax.)
It may indeed be the syntax, but consider that no other language adopted
those constructs. There was a proposal to add contracts to C++0x which
died. I added them to Digital Mars C++ and nobody cared.
Plus, you ignored the other points. Contract inheritance, loop invariants,
ranking functions.
Contracts didn't hit paydirt, and so haven't gotten a lot of follow-on
attention. Eiffel has contract inheritance, I think it has loop
invariants, and I never heard of ranking functions.
* Class/Struct properties (no control over their use by class designer,
no way to use +=, -=, no global properties, no parameterized properties)
I don't understand what this means.
Properties. Your syntactic sugar:
int i = c.p; // int i = c.p()
p = i // c.p(i)
They can't do these things:
* No control over their use by class designer: ANY member function with one
or zero parameters may be called using 'property syntax'. This is not a
good thing.
Why not? Seriously, what is the semantic difference?
* No way to use +=, -=: I hope this one is clear. The operators that require
both read and write access won't work on properties.
Agreed that's a problem. Andrei has also been a strong advocate of
fixing it.
* No global properties: If I'm not mistaken, global functions can't be
properties.
int foo() { return 3; }
void main()
{
int x = foo;
}
works.
* No parameterized properties: c.f(5) = 6; // c.f(5, 6)
Ok.
* Operator overloading (no fine control over comparison operators,
> fixed commutativity,
This is deliberate. Operator overloading should be restricted to
implementing arithmetic like operations on objects, not completely
different things like what iostreams, Spirit and Boost::regex do.
Arithmetic like operations like matrix multiplication (which is not
commutative)?
I believe this is completely controllable with D.
confusing rule priority to determine translation,
The alternative is "Koenig lookup", which I guarantee is far more
confusing and has many weird problems.
Perhaps you misunderstand. I was referring to the algorithm that first
checks for a complete match, then tries the 'reverse overload', then tries
the commutative call.
I did understand it. The alternative is Koenig Lookup, and the reason
for its existence. Reverse operator overloading is a bit awkward, but
the awkwardness is restricted to the class in which it appears. ADL
(Koenig Lookup) spreads awkwardness everywhere.
no overloading of !, &&, ||,
That's deliberate. For !, I wish to maintain the property of negation of
the boolean result, as much of the semantics of transformation depend on
it.
I can perhaps understand this one. Though I'm sure there are programmers
that'd rather have the ability to overload it.
I'm sure there are, too. That doesn't mean it's a good idea! Features
ought to have compelling use cases for them, not just it-would-be-nice-if.
For && and ||, they are "short circuit" operators, and how that
would sensibly interact with operator overloading I have no idea.
See my comments above about lazy parameter evaluation. I suggest that those
operators are defined with a lazy second parameter for bools, and
programmers should be allowed to overload them for other types as they
please.
I know of no language that allows overloading && and ||.
C++ does. ! too.
Oops, you're right. Here's an old thread about it:
http://www.digitalmars.com/d/archives/digitalmars/D/18153.html
I can't recall ever seeing anyone use it, though. Until there's a
compelling use case for it, not just it being a nice idea, I'll stick
with my belief it's a bad idea.
* Tuples (no dedicated syntax, no parallel assignment, no non-flattening
tuples without workarounds, no returning tuples)
The flattening thing is a problem. The rest can be done with better
library support.
You cannot get a dedicated syntax with library support.
Of course that's true, but why is a dedicated syntax better than Tuple!(
...) ?
I've mentioned I'm working on a programming language myself. I haven't
mentioned its name here, because I didn't think it'd be appropriate. But
with your permission I can post a link to a page describing my tuples.
Sure.
* Unit testing (not at compile time,
You can do testing at compile time with static asserts.
Not unit testing, surely.
You can use static asserts to, at compile time, check the result of any
computation, including function calls, that the compiler is able to
execute at compile time. It sounds perfectly usable as unit tests to me,
and in fact I do use static assert that way.
Perhaps. But all these available but underpowered features make D look like
a playground rather than a serious language. It's as if you think of a new
feature, try it out for a week, then abandon it (I know, I'm exaggerating).
I replied more on unit testing in another response in this thread.
Yes, but 'pretty clear' does not a spec make. I refer you to our earlier
divide/modulo discussion.
We're going to fix the modulo thing. But the C++ standard leaves it
implementation defined. How is that better?
And how about the C++ source character set and the behavior of "char"?
It's a standardized specifying of a mess of implementation defined and
undefined behavior.
Sure, the D spec has gaps in it. But the C++ standard also has large
gaps of uselessness in it.
