rename std.typetuple to std.meta

[MartinNowak]

No description provided.

[MartinNowak]

Rename detection and blame work with git offline, not sure why github fails to do this.

[WalterBright]

Wouldn't it be better to use git mv instead of rm and add? That would dramatically reduce the diffs.

[andralex]

@WalterBright interesting. @MartinNowak is it possible to mv a file and then add a new one with the same name in the same commit?

[WalterBright]

Even if it has to be done as two separate PRs, it is mucho better.

[MartinNowak]

Wouldn't it be better to use git mv instead of rm and add?

That doesn't matter, git doesn't record file moves, it uses a heuristic to detect renames.
That heuristic works here, but github fails to correctly show that.

[Hackerpilot]

That heuristic works here, but github fails to correctly show that.

For whatever it's worth Gitlab has the same issue.

[MartinNowak]

Ping

[andralex]

diff is hard to review side by side but fingers crossed...

[andralex]

Auto-merge toggled on

[mihails-strasuns]

Huh, so in the end you decided to with the change but with the inferior implementation and missing documentation update? (Spotted the PR in the weekly newsletter)

At this point I have no idea about upstream rationales anymore.

[JakobOvrum]

There's also #3264, which was merged even though @andralex appears to be arguing against it in this comment...

I am confused.

[mihails-strasuns]

Yeah seems like in the end it is almost the same as my original proposal but without the package split, slightly different naming (Arguments) and without documentation updates (both in Phobos and the website). Including bunch of changes that were initially stated us unacceptable.

[dnadlinger]

wat.

[Hackerpilot]

😞

[John-Colvin]

Yeah this is totally confusing. I quote:

Me:

Tuple needs to be entirely erased (aliases for backwards compatibility excepted) from phobos unless it's referring to std.typecons.Tuple.

@andralex:

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 MetaList!

Please stop.

And yet here we are, with exactly that.

[MartinNowak]

Huh, so in the end you decided to with the change but with the inferior implementation and missing documentation update?

This was the minimal change set to get rid of TypeTuple, which was the main point of #3128.
Walter has explained pretty clearly why renames are costly and therefore proposed this reduced change.
#3128 (comment)

I know it's tempting to throw away one of the crappy modules and just rewrite it, but we need to become a lot more conservative with this kind of changes and only do things that really justify to ask everyone to change their code.

It's also a bit unfair to entangle someone in a highly dynamic discussion and then held him liable for everything he wrote, controversial discussions work a lot better without emotions.

[mihails-strasuns]

It still does all the most intrusive renaming. If you tried updating it for the Phobos (and not leave it as a technical debt) it would become more obvious. Please, stop making compromises in implementation. Compromises and discussion should happen about goals and intention, with actual implementation always backed by technical points exclusively. Otherwise you will get something half-finished that takes worst of both worlds (in this case - both does intrusive change and leaves lot of stuff unfinished).

What decisions are made is less important than how those decisions are made.

I also disagree (a lot) about being conservative but that will be part of my DConf talk so no off-topic here :)

[mihails-strasuns]

Just to be clear : I am not against this specific PR or any other. It doesn't matter if I like it or not personally. What important to me is having a clear understanding of upstream development vector and rationales, because it is part of my actual job responsibilities. And I feel like this is exactly what I have lost by now.

[andralex]

We're making decisions on a case basis and at face value to the maximum extent possible. (These are both important because they caution against using one change as precedent justifying another.) @MartinNowak explained the background of this well. In the case of naming it's impossible to explain things 100%, or to please everyone. We replaced a really unhappy choice (TypeTuple) because it was a net liability for learning the language. Walter argued to replace a few others (ParameterTuple etc) - I didn't agree or disagree much with these. All work does not break backwards compatibility (including by means of deprecation).

Improvements to documentation are of course gladly received. And of course, adding new value on top of what we have is the best step forward. This particular discussion has run its course - at least I have no wits to add to it.