Remove the std::num::Times trait

[brendanzab]

Times::times was always a second-class loop because it did not support the break and continue operations. Its playful appeal (which I liked) was then lost after do was disabled for closures. It's time to let this one go.

[flaper87]

I liked the .times syntax 😢

[brendanzab]

Let's discuss this further before r+-ing.

[brendanzab]

Rebased with some fixes.

cc. @bstrie

[brendanzab]

Another opeion is to have a Times iterator.

for () in 10.times() { ... }

[brendanzab]

@flaper87: even without do? I thought the 'englishiness' of do x.times { ... } was the biggest appeal surrounding the method, hence why folks put up with its deficiencies as opposed to the language-supported iterators.

[liigo]

I like times and do,, don't remove them!

2014年1月20日 上午7:11于 "Brendan Zabarauskas" notifications@github.com写道：

@flaper87 https://github.com/FlaPer87: even without do? I thought the
'englishiness' of do x.times { ... } was the biggest appeal surrounding
the method, hence why folks put up with its deficiencies as opposed to the
language-supported iterators.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/11672#issuecomment-32725530
.

[thestinger]

@liigo: do for closures is already gone

[brendanzab]

As @thestinger says, do notation only remains for procs, and it is up for debate whether even that should even be retained. I used to be a proponent of do, but I'm thinking it might be better to remove it entirely. spawn(proc() { ... }) isn't really that bad.

But anyway, the discussion of the fate of do for procs is beyond the scope of this PR. The important thing is that the syntax has been removed for closures, removing one of the nicest things about the Times::times method.

[adrientetar]

Rust is not ruby; I don't see why we'd want to have literal syntax über alles.

Do is partly gone already and keeping it just for that makes no sense imo, I think it makes sense to cleanup the Times trait too; it not only lacks break and continue but (I think?) you can't make use of the iterator in the loop.
That being said, it would be cool to have the possibility to omit the first argument to range() for conciseness.

The do thing:
do i.times()
Range:
for _ in range(0, i)
What would be cool:
for _ in range(i)

[flaper87]

FWIW, I meant to say that I liked the old n.times syntax, not that I'm voting to keeping it around the std. If for _ range(n, i) is better in every way than .times then I agree, we shouldn't keep it around.

As for the range(i) thing, I don't see what's wrong with just using range(b, i) which sticks more closely to the definition of mathematical intervals.

[adrientetar]

@flaper87 range(i) keeps the "do it i times" idiom, but with the power of range iterators. This is a possible pattern in Python.

[brendanzab]

range(i) is kinda odd. It's not a range, just a single value. It's also not possble to have both in Rust - we don't have function overloading.

[flaper87]

Exactly my point. I know python has support for it. I just don't think we
should have it in rust. I don't personally like the implicit semantics of
it.

[adrientetar]

Means "range with i elements" to me, doesn't seem that odd.

[brson]

+1

[alexcrichton]

r=me with a rebase, sounds like we've got enough people on board.

[brendanzab]

Ok, I'll try to update this.

[brendanzab]

This seems to have already been done since I made this commit. Good work guys!

[brendanzab]

Oh huh. I think I made a mistake. Still there. Ok, I will still work on rebasing. Sorry!

[brendanzab]

Ok, rebased! r?

[bstrie]

Good riddance! :)