Move std.typetuple to std.meta.list

[ntrel]

https://issues.dlang.org/show_bug.cgi?id=4113

Part of DIP 54.

My plan of attack is to create std.meta.list as described in the DIP, then work on updating dlang.org and remaining Phobos modules not to use tuple for template argument lists. I don't intend to work on std.meta.pack as that seems additional functionality best done by someone else.

BTW I think the DIP also needs to mention what happens to .tupleof - copying @Dicebot.

For the documented new symbol name for TypeTuple, TemplateArgumentList, I think the 'Template' word is redundant because there's always a '!' after the symbol, e.g. TemplateArgumentList!int, so the reader knows it's a template. I suggest we use just ArgumentList or ArgList. It's still descriptive, and we need a short name (e.g. for easy use in unittests) otherwise everyone will just alias it differently. But I will change this if necessary.

• Rename std.typetuple to std.meta.list.
• Deprecate std.typetuple.
• Rename TypeTuple -> List, recommend import meta = std.meta.list (as discussed below).
• Update std.meta.list docs to mention template argument list or just list instead of tuple.
• Update makefiles.
• Fix remaining uses of std.typetuple, TypeTuple in Phobos.
• Rename some symbols for consistency (see discussion below & commits).

[mihails-strasuns]

Thanks a lot for pushing this!

I think I should provide more context where my original attempt to implement DIP54 has stalled. I wanted to provide a bit more fleshed out module before doing the pull request and started with hardest part - overloads based on TemplateArgumentPack. In the process I got extremely dissatisfied with language tools available for implementation of packed tuples and it has led to idea of http://wiki.dlang.org/DIP63 - which proved to be damn hard to implement with current DMD AST structure, at least on my level of dmd competence.

And since surprise addition to Phobos dev team it has been totally stalled because it eats almost all spare time :( In that regard I am happy someone else looking at this and fully approve attempt to start with smaller and more obvious changes so that at least something can happen that way.

On actual naming debate and stuff:

I think the 'Template' word is redundant because there's always a '!' after the symbol

This is not entirely true as function argument list is almost a subset of template argument list and specific argument list provided after ! can fit both. That said, no good name that makes everyone happy was proposed so far (TemplateArgumentList is very purist and many are against it) so there is place for compromises and debates.

I think the DIP also needs to mention what happens to .tupleof

Unfortunately there isn't anything we can do with it realistically so it wasn't mention. Only thing I can imagine is providing Phobos wrapper MemberListOf!Aggregate and encouraging to use it instead of raw .tupleof for readability.

Make std.typetuple publicly import std.meta.list and alias TypeTuple = ArgList.

I don't think it is a good change. Better way to deprecate the module is to just leave it as-is minimizing any potential behavior changes.

[mihails-strasuns]

As for this one:

It's still descriptive, and we need a short name (e.g. for easy use in unittests) otherwise everyone will just alias it differently.

I was initially going to advocate idiom of doing import std.meta.list : TAL = TemplateArgumentList in meta-programming heavy code internals with rationale that it is not utility very common in casual user code and keeping primary name perfectly clear is worth small extra effort for power users to explicitly shorten with alias.

However, practice has shown that even that long name creates confusion in what it actually means so this rationale doesn't hold.

[ntrel]

Perhaps I should start a thread about TAL naming. I don't mind using full TAL though.

Only thing I can imagine is providing Phobos wrapper MemberListOf!Aggregate and encouraging to use it instead of raw .tupleof for readability.

Sounds good.

Better way to deprecate the module is to just leave it as-is minimizing any potential behavior changes.

OK, I'll do that soon.

[ntrel]

Rebased. Now std.typetuple contents are kept, just the deprecation note is added: ntrel@bf83624#diff-2

[mihails-strasuns]

Perhaps I should start a thread about TAL naming

Judging by previous experience that won't result in any agreement :) At least not unless you are going to provide strong proposals of your own, better than existing ones.

[Geod24]

Thank you for moving forward with this !

Some points:

1. The very first item of DIP54 mentions creating std.tuple. Will it still happen ? Another alternative would be to turn std.typecons into a package. @Dicebot ?

Rebased. Now std.typetuple contents are kept, just the deprecation note is added`

Thanks, it makes it much more easier to review. However, now we can deprecate a whole module, and if we provide a replacement, we should do so. A red warning on the website is nice, but users won't notice it in existing code.
3) Documentation of the module refers to TAL when it should refers to ArgumentList.
4) There should be a top level unittest (under the module) which provide idiomatic demonstration of the module's capability (eventually taken from existing code).
5) Question to Phobos devs: Is the exception to naming for eponymous template (3rd point) still considered relevant ? It's true that they are conceptually more similar to functions, and indeed, we have the same runtime-equivalent. This exception basically forces us to prepend static to any function-like template...
6) There's various references to tuple (in unittest / comments), they should go.
7) Thanks for doing this 👍

For the documented new symbol name for TypeTuple, TemplateArgumentList, I think the 'Template' word is redundant because there's always a '!' after the symbol, e.g. TemplateArgumentList!int, so the reader knows it's a template. I suggest we use just ArgumentList or ArgList. It's still descriptive, and we need a short name (e.g. for easy use in unittests) otherwise everyone will just alias it differently. But I will change this if necessary.

I agree to ArgumentList, for a different reason: The current naming convention implies that ArgumentList is a type. Everyone can tell that someSymbol!int is a parametized function, and SomeSymbol!int is a parametized type (Point 5 taken appart). And probably a good compromise between shortness and expressiveness.

[mihails-strasuns]

1. The very first item of DIP54 mentions creating std.tuple. Will it still happen ? Another alternative would be to turn std.typecons into a package.

Yes this now looks to me like a better course of actions. Most of typecons stuff is very independent from each other but DIP54 has been written before package splitting has become hot :) But I don't like the name typecons, newbies pretty much never look into it when checking out what Phobos provides. Even stupid name like util would have been better in that regard :( Anyway, this is something that needs to be approved separately.

5. Question to Phobos devs: Is the exception to naming for eponymous template (3rd point) still considered relevant ? It's true that they are conceptually more similar to functions, and indeed, we have the same runtime-equivalent. This exception basically forces us to prepend static to any function-like template...

AFAIK yes, it is still relevant. What is exactly the problem?

[Geod24]

5. Question to Phobos devs: Is the exception to naming for eponymous template (3rd point) still considered relevant ? It's true that they are conceptually more similar to functions, and indeed, we have the same runtime-equivalent. This exception basically forces us to prepend static to any function-like template...

AFAIK yes, it is still relevant. What is exactly the problem?

A non blocker for this P.R., but as we overhaul this module, I thought we could bring some consistency. I opened a discussion here: dlang/dlang.org#700

[mihails-strasuns]

btw about naming, I am kind of starting to like this proposal by @klickverbot :

My original idea was to have all un-prefixed names in std.meta (e.g. just List or Seq) and encourage use of import meta = std.meta; in code that is not exclusively template metaprogramming.

meta.List does look pretty clear to me

[braddr]

I don't recall ever seeing anything close to agreement that this level of overhaul of these modules is likely to be accepted. I strongly suggest making sure there's buy-off before investing too much time here.

[mihails-strasuns]

@braddr creating std.meta, std.tuple and deprecating std.typetuple has been approved by @andralex at least (I checked the idea with him before even writing that DIP)

[braddr]

It would be very good to get that documented in the DIP and get it out of 'draft' status. I'm sure it's going to produce another round of discussion and controversy.

[quickfur]

Cf. https://issues.dlang.org/show_bug.cgi?id=1945

[ntrel]

@Geod24:

However, now we can deprecate a whole module, and if we provide a replacement, we should do so. A red warning on the website is nice, but users won't notice it in existing code.

Yes; I wasn't sure what the deprecation process is. Do we go straight to deprecation now?

@Dicebot:

meta.List does look pretty clear to me

Looks good.

Also for std.traits.FooTuple I assume that should go to FooList?

[ntrel]

@Geod24:

3. Documentation of the module refers to TAL when it should refers to ArgumentList.

The first one links to the spec term, but the second one I've now replaced with 'template argument lists', to avoid interpretation of TAL as a symbol name.

[Geod24]

@ntrel: #1766 (comment) is always my reference for deprecation process. So we go right for deprecation (as explained). In addition, in this case, it's a bit special: We are moving a symbol, which means we are not going to undocument it, so this part doesn't apply.

[ntrel]

@Geod24 Thanks for the info. Deprecated std.typetuple in a558e04.

[ntrel]

have all un-prefixed names in std.meta (e.g. just List or Seq) and encourage use of import meta = std.meta; in code that is not exclusively template metaprogramming

While that appeals if we were starting from scratch, I think it will complicate the process of porting code to std.meta.list somewhat - users would also have to add meta. prefixes for any other symbols used besides List.

I now think using just Arguments!(foo, bar) would read better than List or ArgumentList, given that it auto-expands. It could still be called a list in documentation.

[dnadlinger]

While that appeals if we were starting from scratch, I think it will complicate the process of porting code to std.meta.list somewhat - users would also have to add meta. prefixes for any other symbols used besides List.

I don't think this is much of a concern. The whole point of std.meta is to start from scratch. The current naming scheme is a mess anyway (staticXyz vs. just upper case, …), and actually, the prefixes are handy there for resolving ambiguities too (see dlang.org#700).

[mihails-strasuns]

I don't think this is much of a concern. The whole point of std.meta is to start from scratch.

I agree. This is pretty much "last chance to get it right" thing.

[mihails-strasuns]

It would be very good to get that documented in the DIP and get it out of 'draft' status.

I will try reaching @andralex and checking on his up to date opinion on topic

[ntrel]

OK, so far we have List, indexOf, Map. Haven't added import meta = recommendation yet.

[ntrel]

I think that's all the changes local to std.meta.list done.

[ntrel]

OK, made a start on this. I'm using meta as a prefix, consistent with MetaList and the module name. When the renames are decided/approved, I can then port Phobos to use std.meta.list instead of std.typetuple.

I looked at #690 regarding templateFoo naming - I agree with @klickverbot that they should really be upper-cased (as the result is a template which can itself resolve to something that isn't a value). So perhaps I could change them to TemplateFoo. That might be clearer than MetaFoo, as the former reinforces that the result is a template. (Plain Foo seemed unacceptable originally).

[mihails-strasuns]

I think plain Foo is OK in cases where Foo evaluates to type or type/mixed tuple but I can live with it being either way. Unless anyone else has strong opinion on topic I leave it up to your preferences.

@JakobOvrum are you ok with proposed naming?

@ntrel this branch needs a rebase, tester fails because of merge conflicts.

[ntrel]

@Dicebot I agree e.g. for Map and existing Filter, these are fine. (My last comment wasn't that clear, I got a little confused). For e.g. templateAnd, because it resolves to a template I think the template prefix is good to have. For e.g. anySatisfy or staticIndexOf I've changed them to have meta prefixes.

BTW, I chose meta as the prefix rather than ct because these templates like anySatisfy instantiate a passed-in template, they don't just run a calculation at compile time. So it seemed more accurate, (as well as being consistent with the module/package name).

Also, I wondered about just having std.meta for now, then the package split can be done later - perhaps it would be more flexible for the future. But doing as you suggested is also fine with me.

[mihails-strasuns]

Also, I wondered about just having std.meta for now, then the package split can be done later

It is generally OK but I'd really like to have std.meta.list as a separate module (with public import from std.meta) in the very first proposal because it allows for much more focused documentation - articles on dlang.org can link to that specific module and internal documentation can explain all tricky bits in great detail with no additional distraction.

I will give a line-by-line read through during upcoming week. For now please try fixing auto-tester failures ;)

[ntrel]

OK. I think the auto-tester failures are just due to std.typetuple being deprecated and still in use.

[mihails-strasuns]

CONFLICT (content): Merge conflict in posix.mak

[ntrel]

Yes. There were no conflicts when I wrote that. Makefile changes will probably keep causing conflicts every few days.

[mihails-strasuns]

Back here. I had a look at actual sources and see that it still moves all symbols to std.meta.list. What I have proposed instead is to move it to std.meta (via package.d) and only to put definition of MetaList in std.meta.list for now. That would allow later to further split symbols in smaller modules while keeping backwards compatibility.

I think the auto-tester failures are just due to std.typetuple being deprecated and still in use.

If you refer to unit-tests, there is a feature called deprecated unittest which prevents deprecation warnings if relevant symbols are used from deprecated test blocks. If you refer to actual usage from other Phobos modules it will need to be adjusted as part of this PR - I can help with that.

[ntrel]

it still moves all symbols to std.meta.list. What I have proposed instead is to move it to std.meta (via package.d) and only to put definition of MetaList in std.meta.list for now

OK, I hadn't realized. Thanks for the info about deprecated unittests.

[mihails-strasuns]

Any updates on this @ntrel ?

[JakobOvrum]

My uncollected thoughts:

---

MetaList is plenty good in my eyes; the only really important thing is that it differentiates itself from a tuple.

---

So we have:

• capitalized with no prefix for templates that evaluate to a type or list of types
• capitalized with no prefix for templates that can evaluate to both lists of types and lists of values
• meta prefix for templates that evaluate to values
  • except when it doesn't collide with anything or the template isn't from std.meta; then it's not prefixed...
• template prefix for templates that evaluate to templates

Are users supposed to remember these rules? We're fixing the problem of conflation with tuples which is the first priority, but I was under the impression that fixing this problem of prefixes and conventions was also on the table, as it too requires "breakage" (users are free to use the old module).

The meta rule seems particularly arcane as the modus operandi for the rest of Phobos is that the module system should be used to avoid collisions, which is why we have std.file.copy & std.algorithm.copy, std.file.write & std.stdio.write, std.ascii.toLower & std.uni.toLower, etc etc.

---

This module adds a bunch of new functionality. The ones I can see: metaAll, metaAny, Alias, isSame. I guess they don't affect the root problem anyway because even without them we'd have the meta prefix due to renamed staticIndexOf => metaIndexOf. However, this PR claims to focus on the renaming part of DIP54, so these were a bit of a curveball for me when I browsed the patch...

---

I've dropped any pretense I had of established naming conventions for this overhaul; what's important is that we're consistent from here on out. I'm not going to oppose merging this PR even in its current state, but I do wish we'd actually solve the naming problems instead of just choosing new but equally arcane rules. I'll give it some thought, although maybe the last thing we need is yet another suggestion for how to structure these symbols...

[mihails-strasuns]

The meta rule seems particularly arcane as the modus operandi for the rest of Phobos is that the module system should be used to avoid collisions, which is why we have std.file.copy & std.algorithm.copy, std.file.write & std.stdio.write, std.ascii.toLower & std.uni.toLower, etc etc.

I'd love it to be that way but it was mentioned as historical mistake and new rule is "no name collisions within Phobos at all". AFAIR specifically @andralex was against adding new name clashes.

[ntrel]

Sorry, I haven't been working on this, I'm not that motivated about this any more.

[mihails-strasuns]

No problem, I will take it over from here on with your permission.

[ntrel]

@Dicebot sure, go ahead.

[mihails-strasuns]

kk, on it, expect replacement PR as soon as I make decisions on few tricky details.

@JakobOvrum regarding any/all - what do you think about defining specific meta.predicates module for those? Maybe even namespace struct MetaPredicates, screw the common sense!

[mihails-strasuns]

#3128