On 11-05-2012 20:28, Mehrdad wrote:
On Friday, 11 May 2012 at 18:16:02 UTC, Alex Rønne Petersen wrote:
On 11-05-2012 20:05, Mehrdad wrote:
1. "templates": they seem to take in just about anything, and return
just about anything. They can be pretty confusing, especially when
youhave 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.
Not sure I agree.
Templates are almost *impossible* to ignore when working with ranges.
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.
Me too, as a matter of fact.
But they definitely aren't intuitive (just judge by the number of
questions about them that pop up on StackOverflow or elsewhere...)
True, but I think what we lack is clear and concise documentation on them.
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.
Yeah probably.
Consider: In C#, you say Array.BinarySearch(arr) to search an array.
It's VERY straightforward.
In D, it's VERY CONFUSING
Library issue.
Yeah, you got me there...
But in practice it doesn't make a difference what the cause is, so much
as what the effect is...
True. I'm just speaking from a purely language perspective. But D is a
batteries-included language, so if the standard library has problems,
you could arguably say D has problems as a whole...
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).
Yes, I agree, but consider that D users should NOT have to work with
pointers to do something so basic, like testing to see if something is
in an associative array!
I agree that the fact that it returns a *pointer* is probably not ideal.
Maybe if D had proper pattern matching, it could have returned some kind
of Option!T type or whatever...
The mere fact that it uses a pointer makes it unintuitive to a large
number of people coming from C#/Java/Python/etc.
But again, most code really won't be doing all that much low-level
metaprogramming.
That's the hope, but I keep on finding myself putting __traits(compiles,
...) on template conditions and such...
I've actually found that std.traits and if () constraints on
declarations tend to work for most of my cases. But YMMV and all that.
--
- Alex
