digitalmars.D.bugs - [Issue 11235] New: Add analog of TypeTuple that does not auto-expand
- d-bugmail puremagic.com (20/20) Oct 12 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11235
- d-bugmail puremagic.com (10/10) Oct 12 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11235
- d-bugmail puremagic.com (10/10) Oct 12 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11235
- d-bugmail puremagic.com (9/9) Oct 12 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11235
- d-bugmail puremagic.com (7/7) Oct 12 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11235
- d-bugmail puremagic.com (9/14) Oct 12 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11235
- d-bugmail puremagic.com (13/13) Oct 12 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11235
- d-bugmail puremagic.com (29/29) Oct 12 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11235
- d-bugmail puremagic.com (7/7) Oct 13 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11235
http://d.puremagic.com/issues/show_bug.cgi?id=11235 Summary: Add analog of TypeTuple that does not auto-expand Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nobody puremagic.com ReportedBy: public dicebot.lv This topic pops up frequently in D.learn when one needs to pass several distinct TypeTuple's as template arguments. Auto-expansion behavior of existing TypeTuple does not make it possible because two will be merged into single argument list. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 12 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11235 Dicebot <public dicebot.lv> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |pull https://github.com/D-Programming-Language/phobos/pull/1633 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 12 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11235 Andrej Mitrovic <andrej.mitrovich gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrej.mitrovich gmail.com 14:34:46 PDT --- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 12 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11235 No, those are quite different. `std.typecons.Tuple` defines runtime tuple (struct). It can be CTFE'ed of course, but it can't contain types (in TypeTuple sense) or aliases (completely), only values and value meta-data. Proposed `Group` acts exactly like `TypeTuple` but do not auto-expand. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 12 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11235 If TypleTuple comparison would have been legal, one could say that `Group!(int, double, foo).expand == TypeTuple!(int, double, foo)` -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 12 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11235 14:55:06 PDT ---No, those are quite different. `std.typecons.Tuple` defines runtime tuple (struct). It can be CTFE'ed of course, but it can't contain types (in TypeTuple sense) or aliases (completely), only values and value meta-data. Proposed `Group` acts exactly like `TypeTuple` but do not auto-expand.Right.. well with Group you end up having a third tuple kind. I think it's best that we wait for a language implementation of tuple syntax (see http://wiki.dlang.org/DIP32). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 12 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11235 It is not a 3d kind of tuple, it is just another syntax for existing TypeTuple. Considering outcome of last tuple discussion threads any changes in that domain won't come any time soon and this small addition allows to implement certain algorithms right here and now. I personally don't mind keeping it in "stdx" part of my projects but it is mentioned quite frequently as a necessary feature [citation needed]. Also DIP32 addresses different issues and won't change the fact that both expanding and non-expanding tuples are needed in different places. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 12 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11235 David Nadlinger <code klickverbot.at> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |code klickverbot.at PDT --- I wonder whether it is worth adding this as an officially supported kind of tuple, or if we should encourage making creative use of the current syntax to keep the complexity low: (untested, just typed it up to illustrate the principle of nesting templates) --- template isEqual(T...) { template to(U...) { static if (T.length == U.length) { static if (T.length == 0) { enum to = true; } else { enum to = isSame!(T[0], U[0]) && isEqual!(T[1 .. $]).to!(U[1 .. $]) } } else { enum to = false; } } } static assert(isEqual!(1, 2, 3).to!(1, 2, 3)); --- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 12 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11235 Main problem with nesting is that it does not allow algorithms with variadic amount of tuples. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 13 2013