On Fri, 22 Jul 2011 02:50:52 +0200, bearophile <[email protected]>
wrote:
Simen Kjaeraas:
int n;
string s;
unpack!(n,s) = tuple(4, "O HAI");
See my other answer. Beside being long and ugly, it doesn't define the
types too. And you can't use it in foreach.
Yeah, I can absolutely see that there are places where this could not
reasonably be used. Initializing const and immutable data definitely is
one. And being able to use it in a foreach would be very nice.
Something that might take us part of the way, at least, would be for
alias this to support typetuples. Thus:
struct Tuple(T...) {
T fields;
alias fields this;
}
void foo(int n, string s) {}
foo(tuple(3, "bar"));
would work. Foreach would direcly benefit from this:
foreach (x, y; zip([1,2,3], "abc")) {} // Look ma! No bananas!
In my opinion a tuple syntax is more important than having built-in
associative arrays. This means I'd like to remove D built-in associative
arrays and replace them with built-in tuples. Tuples are more commonly
useful than associative arrays, and in D there are enough ways to design
a good enough library-defined AA.
The only problem are AA literals, but a bit of sugar can solve this
problem too. In Scala associative arrays look good enough and they are
fully in the library. There is just a -> built-in syntax to define
2-tuples, used to create AA literals.
this could work today, given a proper constructor:
int[string] foo = [
tuple("a", 1),
tuple("b", 19),
tuple("c", -3),
];
or:
auto foo = AA([
tuple("a", 1),
tuple("b", 19),
tuple("c", -3),
]);
Or, if we go bananas:
int[string] foo = [
(|"a", 1|),
(|"b", 19|),
(|"c", -3|),
];
I agree that a shorter syntax for 2-tuples could be beneficial, and
certainly may make more people use it (also, the -> arrow is not
taken yet):
auto foo = AA([
"a" -> 1,
"b" -> 19,
"c" -> -3,
]);
As for actual typing, 5 characters are saved per line for the tersest
version, and only 3 with bananas. Not enough that I'm convinced by
that argument alone, but the more natural feel of the -> syntax has
me intrigued. (these numbers would also be somewhat different if I
weren't nazi about my spaces)
This is not just about what can be done, but also how to make users
actually use the features. I believe, but do not know, that many
users would feel more comfortable with the latter syntax than
the one saying tuple all the time.
--
Simen
