[Not serious] Language not unstable enough

[Hoverbear]

I mentioned on IRC to @bstrie that I built a fresh Raft which hadn't been bumped in 22 days and it still compiled.

This is obviously a bug. I'd like to propose we reopen #666 for good measure.

I'm sorry if this makes anyone mad. It was a minor point of joy to me and I'd like to thank everyone for their incredible work!

[LaylBongers]

+1 this, I was appalled when after a weekend away from a project, it still compiled AND worked as intended.

[bstrie]

There's been some concern in the community that a Rust without overwhelming, unceasing breakage is a betrayal of Rust's joie de vivre. It would be great if the developers could commit to some sort of "Instability Guarantee" to restore our faith in their leadership.

[bstrie]

As we speak I'm working on a patch that changes the fn keyword to func in order to deliberately break every Rust program that has ever been written. Accepting this change in a timely and efficient manner would be just the show of good faith that the community needs right now.

[Hoverbear]

@bstrie I propose something more complicated than something that could be fixed with a simple regex. We should implement hoisting one master, then decide it was a bad idea a few weeks later, just to keep things fresh.

[bstrie]

While we're at it, is it too late to change the name of the language? What is "Rust" supposed to stand for, anyway?

[LaylBongers]

@Hoverbear What if to allow a function to borrow a value, it must call "promise_to_give_it_back" before doing anything else?

[Hoverbear]

@bstrie Because it's where the metal interfaces with us air breathers.

[LaylBongers]

As well, is it too late to propose Rust support for the compile-time politeness enforcement feature that INTERCAL programmers enjoy?

[HeroesGrave]

I propose we rename isize/usize again.

[LaylBongers]

Additionally, I suggest that any code within an unsafe block should not be written in Rust. Unsafe blocks should instead be written in Malbolge to disincentivice using unsafe blocks.

[soltanmm]

Whatever the changes are, please ensure that they come with formal proofs of more headaches from the borrow checker.

[killercup]

Well, now that the breaking language changes are coming to an end, I suggest we instead focus on introducing breaking changes to the most popular crates with patch-level version bumps!

[tailhook]

I think we should introduce another "unsafe"-like construct. I.e. every non-pure function should be marked with "side_effects" marker.

[GuillaumeGomez]

Closures haven't changed in a while, we need to fix that !

[alfiedotwtf]

@bstrie with the 1.0 release coming in only a few weeks, please refrain from introducing new keywords. If you don't like "fn" for functions, how about swapping "fn" with "if" (i.e Is a Function). "fn" could then be the mnemonic for "ForseNda", which means "condition" in Icelandic.

[killercup]

A very good idea, @alfiedotwtf! I'd like to make loops more explicit by prefixing every loop construct with the loop keyword: loop while, loop for, loop loop, etc.

[GuillaumeGomez]

@killercup: Oh nice ! And then, to be even more precise on the condition, we could do loop while for loop, just in case. We're never sure.

[Stebalien]

@killercup
No no no. We don't need all these fancy loop variants. Just get rid of them and add guard statements to loop expressions:

loop {}
loop if x {}
loop if let Some(x) = iter.next() {}

[tshepang]

@Stebalien I actually like that syntax proposal. Is there anything wrong with it that I don't see?

[Stebalien]

@tshepang

1. for loops store the iterator expression (loop if let Some(x) = a.map(...).filter(...) won't work).
2. It's guaranteed to needlessly confuse new users from other languages.

[tshepang]

I don't understand (1). Do you mean your syntax can't work, or that it doesn't work?

[Diggsey]

I think everyone's missing the obvious here: now would be the perfect time to introduce significant whitespace.

However, due to the disagreement about spaces vs tabs, it would be best to standardise on a unicode "em space" character, and error on any other character identified as whitespace according to the unicode spec.

[Manishearth]

I'm rather disappointed by the lack of PRs introducing ICEs in Rust. A compiler without errors is no compiler at all.

Additionally, where is all the undocumented code? I thought @steveklabnik was supposed to ensure that the majority of code is undocumented so that people instead figure stuff out by reading the beautiful Rust source!

[pythonesque]

It is kind of disappointing. How am I supposed to know whether a project has been abandoned or not when its source code doesn't have to have been updated within the last few weeks for it still to be working?

[Stebalien]

@tshepang Actually, we not only could use that syntax but we should! All we'd need is a with statement to emulate for loops. Why write:

for x in a.map(..).filter(..)) {}

When you could write:

with a.map(..).filter(..) loop let Some(x) = _.next() {..} // Obviously, we'd also allow Scala's `_`.

[konstin]

Now that you can't do real breaking changes for Rust 1.0 anymore, you should start writing Rust 2 which changes one of the key concept, e.g. replace the borrow checker with a garbage collecter, so you have to maintain two versions at once, which will ensure there are enough bugs for everyone in every version.

[alfiedotwtf]

@konstin how about going full-circle: introduce manual memory allocation with two new keywords:

* malloc
* free

[Stebalien]

@alfiedotwtf Keywords are so 20th century:

let my_var = 🎁 myvar;
my_var→ 🗑;

[Anachron]

How about swapping all symbols with their name?

let my_var be 1
let mut my_copy_var be a value reference to 2

This will make it easier for people to code Rust, as they wont have to find the symbols in their keyboard anymore, thus speeding up the development even more.

[Stebalien]

let MyVar be two
let mut MyCopyVar be a value reference to two

[Anachron]

This would be the second step, which should follow after all people have successfully migrated to the new command, still allowing underscores in variable names and numbers. A two step migration path leads to more acceptance.

[Gankra]

This is clearly a regression. Breakage is happening too slow.

[sinistersnare]

I think revisiting the mutapocalypse is a great idea 3 days before launch.

[Anachron]

@gankro I think I have to escalate this, things are going way too slowly in breakage and this is clearly an undesired effect by working code. Please have an emergency meeting with the core and discuss a few options mentioned in this thread.

I suggest #24928 (comment) since this would clearly improve writing speed and thus will double if not triple the amount of crates that will come after 1.0 release.

[brson]

I'm untagging all pre-1.0 regressions to repurpose it for stable regressions.

[steveklabnik]

This bug was fun to have, but I'm gonna be the bad guy and finally close it as well.

Thanks for all the smiles, everyone :)