DIP54 : revamp of Phobos tuple types

[H. S. Teoh]

On Tue, Dec 24, 2013 at 02:52:18AM +0000, Jakob Ovrum wrote:
> I think this is just getting absurd.
> 
> The conflation between the naming issue and auto-expansion is so
> bloody dishonest. The DIP looks really good to newbies because it
> addresses the former but then they don't really understand the
> latter (as some have even said explicitly). Further, if this DIP had
> been discussed in *public* earlier, we could've handled this then,
> which could've resulted in an earlier resolution of the naming
> issue. I was genuinely wondering what was holding up the situation.
> Sigh.
> 
> The most important thing here is that std.typecons.Tuple is
> (conceptually) completely unrelated to std.typetuple.TypeTuple and
> other cases of the "tuple" name used to refer to template argument
> lists. This fact, compounded with insufficient and confusing
> documentation, causes the difficulty of learning. We can easily
> rectify this situation without any significant overhaul of Phobos'
> utility templates, which are mostly good as it is.
[...]

So if we only implemented the first part of the DIP, the renaming of
std.typeconds.TypeTuple -> std.meta.list (or whatever, let's not start
bikeshedding this early), along with the documentation cleanup which is
long overdue anyway, would that be more acceptable to you?

As far as the auto-expand vs. non-auto-expand issue is concerned, I'm
not sure why this is such a big deal.  I *have* run into cases where I
needed one in some cases and the other in other cases. I solved the
problem by simply wrapping stuff I didn't want to auto-expand in a
non-eponymous template:

	template SubArgs(T...)
	{
		alias expand = T;
	}

	template NeedsNestedArgs(T...)
	{
		... // make use of T[0].expand
		... // make use of T[1].expand
		... // etc.
	}

	alias Instantiation = NeedsNestedArgs!(
		SubArgs!(...),
		SubArgs!(...), // will not merge with first list
		... // etc.
	);

Unless I'm missing the elephant in the room, both the auto-expanding and
non-auto-expanding template arg lists can be implemented by a 3-line
template declaration each (or 1 line if you use the new parametrized
alias syntax). Which anyone can (re)write in 1 minute. So why is this
such a big deal? Because of standardization? If that's the issue, then
the non-auto-expanding version wins, because you can always turn it into
an auto-expanding list with .expand, but if you're given an
auto-expanding list you have to explicitly wrap it to stop it from
expanding when it shouldn't. Which requires users to reinvent their own
wrappers, which defeats the purpose of standardization.

Another win for non-auto-expanding is if the lists returned by
std.traits.* et al are non-expanding by default, then you can pass them
straight to another template as arguments without needing to worry about
them flattening and merging where they aren't supposed to. Again, if you
*want* to concatenate those lists, you can just use .expand (which also
has the advantage of self-documenting exactly what is wanted -- the
normal expectation is that separate arguments don't magically flatten
out on you -- unless you're thinking of Perl lists -- so it makes sense
to make expansion explicit).  Going the other way requires that *every*
returned list be explicitly wrapped with a custom wrapper, which seems
to be putting the weight on the wrong side of the boat. Is it really
*that* common to want your lists auto-expanded by default?

Or am I missing something obvious here?


T

-- 
A mathematician is a device for turning coffee into theorems. -- P. Erdos