Andrei Alexandrescu: > Well I think a language can only have so many built-in types. We can't > go on forever.
Too many built-ins become confusing (see Fortress), but D is quite far from that point (see Python, that has more than D and they are just fine and easy to use and remember. I'd also like to add a set literal to the D syntax, semantically implemented in the std library). On the other hand Scala language shows that a good language allows you to remove things from the language/syntax and implement them as libraries (Scala moves in the libs several things that are built-in in D). So it's a dynamic balance, things go, things come. But note that collection "literals" of Scala are worse than Python ones. --------------- Sergey Gromov: >Comma expression is not ambiguous. It's a comma expression. Renaming it into >a tuple constructor expression does not add any ambiguity. Parentheses here >are only required to separate the comma expression from an assignment >expression which otherwise would become a part of comma expression.< Python has tuples, but their syntax has some holes I have never fully loved. See: Empty tuple: () Tuple with 1 item: 1, Or (1,) Tuple with two items: 1, 2 Or: (1, 2) They also support smarter forms of unpacking (Python 2.6): def foo((x, y)): Now if you pass foo a pair (a 2-list, 2-tuple, 2-string, 2-lazy iterable, 2-array, 2-set, 2-dict, etc) you have available and assigned x and y inside foo. In the following syntax (Python 3.0+), c becomes assigned with all the items following the second one: a, b, *c = baz In the end I don't like the use of () to denote tuples (well, in Python most of the times it's the comma that denotes a tuple, only empty tuples needs () ). So better to use different ways to denote them. Bye, bearophile
