Introducing std.meta package #3128
Conversation
|
While trying to migrate test of Phobos to new paths I have encountered interesting issue - random template constraint failures when those use aliased template symbols and cyclic imports are present. Damn hard to reduce that because in Phobos cycles are everywhere. Has anyone encountered that before? |
|
FYI: this is currently blocked on automatic renaming tool to make actual migration as smooth as possible for end users. |
|
Do you have something like this in here yet? https://gist.github.com/John-Colvin/2df6f4f12bfdadc10237 Or should I wait until the dust has settled? |
|
@John-Colvin I tried very hard to resist temptation of actually improving things in the same PR :) Let's finish with initial 1-to-1 migration first. |
|
Should be green now, I have cleaned all references to deprecated symbols in Phobos itself and rebased. |
|
What remains : reading through docs and providing replacements for symbols in My attempt at creating automatic migration tools based on DCD can be found here : https://github.com/Dicebot/DCD/tree/renamefixdirty , however it was discovered to be unacceptably sub-optimal and not really fitting existing DCD architecture. I am waiting for @Hackerpilot guidance on this but creating something proper could take a long time so it is not in scope of this PR anymore. |
|
Correction : will be green after merging dlang/dmd#4613 |
|
@MartinNowak could we possibly aim this for 2.068? |
| @@ -37,16 +40,17 @@ module std.typetuple; | |||
| /** | |||
| * Creates a typetuple out of a sequence of zero or more types. | |||
| */ | |||
| template TypeTuple(TList...) | |||
| deprecated("Renamed to std.meta.list.MetaList") | |||
| template MetaList(TList...) | |||
OK, let's do it, we shouldn't deprecate std.typetuple right away though. |
@andralex has asked to not do this and keep deprecated old std.typetuple as is. |
|
Ah, actually my memory is wrong, he asked to do the other way around : #2687 (comment) Will do. |
|
Updated: replace deprecation with documentation update that indicates deprecation is coming one release after. |
|
Updated with cleanup for other mentions of This pull is ready from my side. Only thing that remains is matching PR to Ping @JakobOvrum @MartinNowak |
|
Other than that, LGTM. Glad that this mostly makes template constraints shorter, as they had a tendency to get a bit long-winded. |
|
I used fully qualified path initially to make error messages more obvious to myself in case I screw something. Will try removing that and see if it still works. |
|
Yep, seems to work with exception of two places. |
|
Can't reproduce the failure locally. Is it something about auto-tester? |
Yes. Just deprecate the test |
|
@schveiguy which test? Sorry, I don't even understand what this error relates to. |
|
In the auto tester. You just deprecate that test and it will rerun Sent from my iPhone
|
|
Related dlang.org PR : dlang/dlang.org#986 Is anything blocking this PR? It needs regular rebases to stay green so I'd prefer it to be merged a bit sooner if there are no more issues ;) |
|
Ping |
I won't argue this much, but I question this assertion. Per m-w.com: "set of (so many) elements —usually used of sets with ordered elements". The trouble is with Type because a TypeTuple can contain things that were emphatically not types. If you convinced me it wasn't the Type part that was confusing, then I'd be against any renaming whatsoever.
TypeTuple barely makes the bar for renaming, the others I don't think do. Please let's not turn this into a negotiation. I said and I repeat: some of the new names are clearly better but not enough. There's no intrinsic value in renaming ParameterTypeTuple to Parameters - either way it has to have a name that has to be found by perusing the documentation. It's not something natural that can be inferred without any lookup. Tomorrow someone comes with the |
I agree with the logic, but it's irrelevant - the issue is that users confuse std.typecons.Tuple with template argument lists.
The issue has always been the name "tuple". Feel free to dig up the old threads and verify.
This ignores the root issue that is the inappropriate overloading of the concept "tuple" in the D ecosystem. |
I disagree. I don't see a problem acknowledging there are tuples of values and tuples of other things. By the same argument, "List" should be removed unless it refers to a list of values - wait a minute, this very diff has a Please stop.
Breaking 50+ modules of Phobos doesn't seem quite inspiring for those folks who've been using metaprogramming and will find they need to change names in random ways.
Yeah, it's always different this one time, or it's the last time. Please do not. We can't afford all this anymore. |
If that's the root issue here, we can sleep soundly. |
Wisest words in this thread. Thanks @MartinNowak |
You're free to dismiss the problems newcomers face at your own disadvantage as co-head of D, but at what gain? This doesn't break any code and it doesn't ever need to. Even the DIP states the problem quite clearly in the rationale and description. You've been participating in the process all along, you don't get to claim to be ignorant of the rationale and shoot it down now on that basis.
This was always in the back of everyone's heads. See comments like this one. Breaking code doesn't further the cause in any way. What we need is a distinction between the two "tuples" so it's actually possible to teach these things to beginners. The cost of this is two-fold; 1) all the work that people like @Dicebot had to do to fix the situation which has already been paid, and 2) the trivial cost of maintaining the old symbols for compatability. |
I thought I was dismissing a problem you assert to exist.
If I participated in the discussion, it doesn't mean I automatically must accept whatever comes out of it. This is not shooting down and please don't attempt to make it an ethical matter for me. I'm all for good work that makes Phobos better. I won't accept code because it has a DIP that's been discussed and because it's extensive. It is Walter's and my assessment that this work does not improve the lot of current and future D users. |
Yes, it does. std.typelist is removed and several declarations are deprecated in std.typetuple. Furthermore, these renamings obsolete books, articles, and tutorials written about D. And lastly, there have been several of these grand renamings, each billed as the last one.
I find this as upsetting as anyone, as we cannot squander effort. But adopting something because a lot of work was put into it, rather than on its merits, is the sunk cost fallacy: http://en.wikipedia.org/wiki/Sunk_costs |
If that's the case, then we're back to square one. I'd like to forget about this massive waste of time as soon as possible. |
|
I think it is just about time to start Phobos community fork. This has become ridiculous. |
|
I am fine with never deprecating old names and just keeping them around undocumented. However the whole "tuple" dichotomy is very expensive and needs to be killed. I spend much more time explaining new devs weird naming than I would spend updating the cost. That is clear RAI win. |
|
TypeTuple is clearly a misleading name, and is causing ongoing problems. But using that as justification for a grand renaming is a costly overreach. And changing
This is the least disruptive change while preserving the value. |
|
As it was already pointed out There is much much less implication that And I won't accept any solution that won't result in creation of If you want to keep old modules and names as-is to preserve old programs compiling - that is fine and reasonable. But current situation is so tremendously bad that anything less than full new layout and naming convention simply won't make a difference. |
It currently simply follows Phobos style guide (types start with capital letter, values with lower case letter). It is however true that it doesn't fit well with something that is neither type nor value :) |
|
@WalterBright that sounds reasonable, with one exception: std.meta is a package for manipulating and creating compile-time objects. This isn't the same as the general templatisation of phobos. If you really think it's not worth it then so be it (I strongly disagree here), but that's not a valid reason. |
|
@Dicebot As you say, many of D's constructs have unique characteristics and so using other language semantics as a guide has only limited utility. D tuples, for example, can be indexed which is not an implied characteristic of a list. Hence, renaming them to lists is a step sideways. Your idea of simply appending @John-Colvin Everything in Phobos is going meta. Any package called meta is just going to become another "scrapyard" (to borrow Dicebot's term). It's not just templates, there'll be a lot of meta stuff that is specific to what a particular module is about. For example, I don't see value in moving a meta template that is specific to strings into It all reminds me of my doomed attempts at categorizing my book collection (5000 books) on my computer. Do I organize them by subject, author, genre, quality, already read, age? All books fit nicely into multiple genres. There is no solution. There's no hierarchy of Phobos modules either that is going to work - the only thing we can do is just take a stab at it an provide better search/discovery methods. Trying to deal with this by having more modules that merely contain lists of aliases is not solving the problem, either, it just adds to the burden of anyone trying to understand someone else's code. I'll reiterate that these endless quests for the perfect names and taxonomy is, in the end, a waste of time and destructive of D by adding cruft, baggage, and impeding communication between groups of programmers. We've had grand renamings in the past and I have yet to see a single comment of the form "Phew! what a relief that was done!" from any who didn't have a dog in the hunt, nor any evidence of improved productivity. But I have seen an awful lot of "D has never left beta", "D won't compile last year's code", "D is unstable", "D's developers cannot make up their minds", and the worst: "D's real problems are not getting resolved." None of these renaming proposals are going to make code run faster, be smaller, compile faster, or be more correct. All of them consume vast amounts of our time, and an uncounted amount of time for the silent majority that use D out in the field. Criminy, this proposal required FIFTY modules in Phobos to be changed. FIFTY. This is not going to happen. We must be far more modest about changing a name. What I listed above is the minimum that resolves the issue, and that's why it's the solution we're going with. Revert this, do the renamings I enumerated above, and let's move on. |
|
You get "D unstable" comments about breakage called "bug fixes" and instead of taking more care about that, interpret it as an argument against doing cleanup at all. I have seen this attitude from you for years now - can't realistically hope it will change, but this is one of worst things about trying to collaborate with D upstream in general. I wonder if you have noticed that this PR breaks no code. At all. I have spent about one week total doing this PR. I have about that the same time total already answering questions and investing into documentation to try to compensate horrible naming and Phobos layout in this domain. And much much more time to actually figure out the details when I was initially studying this topic on my own. "Not worth it".
Changed those module to keep sources good, clean and up to date with "idiomatic" style. It wasn't required.
Revert it and stop wasting my time. Your suggestion is crap and would make situation even worse - current naming is bad, but it is at least consistently bad. |
|
Also,
http://dlang.org/template.html#TemplateParameterList - I haven't really invented this naming. We had huge amount of debate and all suggestions felt bad. This one was chosen as "least worst" compromise. |
std.typelist was deleted, and std.typetuple is deprecating several names. That's breakage, as well as breaking books, articles, and tutorials.
My feeling as well. I know you have invested significant time in this, and I'm sorry about that. I'm sorry that we haven't been able to reach consensus, but someone has to make a decision, and that's me. |
|
Deprecations don't break code - that is the very reason why those exist. As for |
@WalterBright I'm not sure I understand you. I am talking about things like Zip, Filter, Sort, CartesianProduct and so on that work with what you are referring to as Arguments. It's not about using std.meta as a dumping ground for every specific piece of metaprogramming used in phobos, it's about providing a set of general tools, like std.algorithm/std.range do for ranges. |
|
I'm not invested in this argument over naming in any way, but I'm curious as to how marking something deprecated constitutes a code breakage. Isn't the whole point of deprecated() that it discourages the use of a symbol without breaking code? Even then, I thought there was a well-defined path to deprecation, such that std.typetuple would not be marked as deprecated outright, but 6 months down the road. |
I think you answered the question - deprecation does break code, it just does it in a gradual, nicer manner, rather than abruptly. It still forces people, sooner or later, to go and edit their code because it won't compile anymore. It still causes working libraries that aren't actively maintained to break. It still means that an older project pulled from somewhere won't compile anymore. It still means that books that have examples using TypeTuple become obsolete. |
For some reason I suddenly remember Scott Meyers. |
|
(no, it is not necessary to actually remove deprecated symbols) |
|
It won't break code unless you're using the -de compiler switch or the symbols are eventually removed. |
|
Selectively overlooking deprecations is not a generally practical strategy for users, and we should not be advocating it. They're all or nothing. |
Follow-up to #2687
Changes from original PR:
staticandtemplateprefixes from names now that they have own module namespaceMostDerivedandDerivedToFronttostd.traits(no idea why those added tostd.typetuplein the first placeTODO:
std.typetuplefor each specific symbolstd.typetuplein Phobos itselfTypeTupleas part of their nameI hope I have resisted all urges to improve / enhance actual functionality of moved templates.
(poke @JakobOvrum)