On 2013-08-21 16:59:17 +0000, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> said:
On 8/20/13 8:25 PM, Michel Fortin wrote:
On 2013-08-21 00:38:30 +0000, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> said:
1. What do we need?
I think D needs less tuples. It has two kinds (language kind and
Phobos's kind), which is confusing. It should have just one that covers
most use cases.
Yah, fewer tuples (or assigning distinct names to what we call today
such) would be awesome.
That seems like the only thing everyone agrees with. :-)
I'm unfortunately lost already. I was discussing tuples as in
"anonymous structs", not as in "template tuples".
Well, the original post that started this discussion talked about both.
I don't think narrowing it only to "anonymous structs" is going to
solve the syntax problem as a whole.
int a, b, c, d, e, f;
swap(...(a, c, e), ...(b, d, f));
This looks like an example taken from a book in which "..." means some
stuff is omitted.
Seriously, the major issue with tuples is a conceptual one. No pretty
syntax is going to fix it alone. Unfortunately, talking about concepts
requires inventing a syntax for them. The syntax then immediately get
dismissed as ugly/impractical and no thought is given to what's under
it. No wonder this is getting nowhere for the nth time when everyone
thinks so superficially.
Just disregard the "..." syntax. It makes sense in the context of my
other post. There's no way to appreciate it without that context (and
even then, it can surely be improved).
The idea (in my other post) was to un-cripple language-level tuples
with one simple fundamental change: allow them to be packed and
expanded. With that you can cover 99% of what you want from a tuple
struct using the built-in language-level tuple. Plus you can do some
other things like the swap of aliases to variables shown above.
There is no reason for template-argument-tuples to be auto-expanding.
If you fix that, as I proposed in my other post, you'll almost never
need a library struct template to represent a tuple anymore. Thus,
fewer tuples.
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca
