On 11-05-2012 20:05, Mehrdad wrote:
On Friday, 11 May 2012 at 17:47:06 UTC, Alex Rønne Petersen wrote:
Complicated language structure? Long compilation times?

wat.

I'd have to agree...

Several things in D are really hard to understand if you don't already
have a C++ background:

1. "templates": they seem to take in just about anything, and return
just about anything. They can be pretty confusing, especially when you
have to worry about overloading vs. specialization vs. constraints, or
types vs. aliases...

Right, D's template system is definitely inspired by C++, no argument there. But in the vast majority of code, you really don't have to use templates for everything.


2. Tuples (I'm referring to both tuple() and TypeTuple()) are very
confusing if you don't happen to suddenly "get" them.

I don't know about that. They seemed simple enough to me.


3. Ranges aren't confusing, but USING them certainly is.

On the contrary, I actually think we're lacking proper documentation on what ranges are.


Don't believe me?

Consider: In C#, you say Array.BinarySearch(arr) to search an array.
It's VERY straightforward.
In D, it's VERY CONFUSING -- there *is* no way to do this directly!
Which led me to ask this question:
http://stackoverflow.com/questions/4622377
and the solution indeed was NOT something I would've found by myself
without spending hours on it (which I already had partially done).

Library issue.


4. is(typeof(foo) U) is very confusing; it's completely unintuitive

5. For that matter, is() is completely unintuitive

Definitely. is() is an abomination.


6. The 'in' operator returns a pointer (instead of a boolean). Which is
fine, except that it's not what you'd expect in any languages other than
C/C++. i.e. Non-intuitive

I've always found it very intuitive actually... and it saves me from having to write extra code to do the actual lookup (speed isn't even the point here, I just want concise code).


7. __traits() are confusing

I have the same stance WRT __traits as I do for is(). We need a better solution to metaprogramming.

But again, most code really won't be doing all that much low-level metaprogramming.


8. there's more but I just can't think of them right now

--
- Alex

Reply via email to