Forbid pineapple on pizza by emilyalbini · Pull Request #70645 · rust-lang/rust

emilyalbini · 2020-04-01T07:17:56Z

This PR adds a new forbid-by-default lint to the Rust compiler, preventing users from writing wildly untasteful types such as Pizza<Pineapple>.

r? @estebank
cc @steveklabnik, what do you think is the best way to document this feature?

_{This was inspired by @sgrif's awesome RustConf 2017 talk. Check it out!}

killercup · 2020-04-01T07:41:59Z

I work with a lot of international people and even some linguists so our code bases are always fully translated. For increased coverage, can you maybe also disallow "ananas"?

dns2utf8 · 2020-04-01T09:25:05Z

I love Ananas on Pizza, can I invert the lint too?

#[allow(pinapple_on_pizza)]  // for liberals
#[enforce(pinapple_on_pizza)] // for me ;)

Centril · 2020-04-01T10:04:18Z

+   |            |
+   |            this is the pizza you ruined
+   |
+   = note: `#[forbid(pineapple_on_pizza)]` on by default


Given the atrocious crime against taste that has been committed here, I wonder if we should delete the file from the user's hard-drive. Although, I'm not sure how to test that... 🤔

We could get close by obtaining the whole span of the file and adding a removal suggestion to remove the complete span. Since we have rustfix tests this should be easily testable 🤔

Ah that's clever! @pietroalbini Can you adjust the PR to do that?

Can you get the span of the whole crate?

jamesmunns · 2020-04-01T10:05:05Z

I think it is irresponsible to land these kinds of changes without an associated RFC. I, for one, find pineapple based toppings wonderful. For example, this would disrupt my workflow around creating my favorite pizza:

#[allow(pineapple_on_pizza)] // UNACCEPTABLE!
let _: Pizza<(Pepperoni, Pineapple, Jalapeno)>;

If I was forced to allow this lint every time I instantiate my favorite pizza, I think this would be a total blocker for my use of Rust.

Dexterp37 · 2020-04-01T10:30:17Z

Please, let's merge this ASAP. I would make my life so much easier if this would become a de-facto standard.

kornelski · 2020-04-01T11:34:44Z

I think this feature is overly specific. For example, I'd also like to have warnings about Anchovies.

And it doesn't work for Marmite/Vegemite types.

Dylan-DPC-zz · 2020-04-01T14:42:18Z

We need an fcp for this.

bjorn3 · 2020-04-01T14:45:31Z

Does this need a fcp with all teams? This concerns preventing a crime against the taste of everybody.

jyn514 · 2020-04-01T14:47:15Z

+
+declare_lint! {
+    pub PINEAPPLE_ON_PIZZA,
+    Forbid,


I don't think this needs its own lint group. It should go with other similar lints, like allow(bad_style).

Not allow(bad_style), but allow(bad_taste).

I don't think we should allow pineapple pizza to be instantiated regardless of the pragma or directive. We shouldn't permit terrorism.

Ixrec · 2020-04-01T14:56:47Z

Unfortunately toppings are generally chosen at runtime, by the user, so a compile-time lint would catch almost nothing in practice.

Clearly, the only proper solution here is a full-blown effect system with dependent typing (and probably generic modules just to be sure), so we can statically verify that e.g. calling .sort() on a VecWithPineappleAtTheEnd turns into a VecWithPineappleWherever. That will definitely require an RFC. Or fifty.

Dylan-DPC-zz · 2020-04-01T15:24:28Z

I work with a lot of international people and even some linguists so our code bases are always fully translated. For increased coverage, can you maybe also disallow "ananas"?

You need to contact the localisation team for that. I've added it to their non-existent agenda.

nagisa · 2020-04-01T16:26:07Z

+struct Pineapple;
+
+fn main() {
+    let _: Pizza<Pineapple>; //~ERROR pineapple doesn't go on pizza


A test is necessary to ensure that this lint fires regardless of the order in which – or count of – ingredients are applied to the base.

amanjeev · 2020-04-01T17:00:54Z

Removing Pineapple will reduce the cost of pizza as well. Isn't something zero cost something a thing here?

bjorn3 · 2020-04-01T17:06:02Z

I don't believe we allow negative cost abstractions.

Centril · 2020-04-01T17:40:07Z

We should have accepted @Gankra's RFC (rust-lang/rfcs#1963) which enabled NCAs!

jebrosen · 2020-04-01T18:02:36Z

Does this (and should this) PR see through type aliases? It would be good to document whether type Mushroom = Pineapple; is a suitable workaround for this lint.

cuviper · 2020-04-01T18:07:04Z

It would be good to document whether type Mushroom = Pineapple; is a suitable workaround for this lint.

Speaking as a fan of both, that alias is an abomination.

Dowwie · 2020-04-01T18:11:31Z

Pizza<Pineapple>, one of the most unsound combinations, deserves its own CVE.

Dylan-DPC-zz · 2020-04-01T18:13:46Z

Folks, pineapple is UB

kush-patel-hs

LGTM

Aaron1011 · 2020-04-01T18:36:26Z

+                        continue;
+                    }
+                    for arg in args.args {
+                        if let hir::GenericArg::Type(hir::Ty {


This should be extended to support const generics:

Pizza<pineapple()>

should not be allowed, since there is no value to having pineapple on pizza.

estebank · 2020-04-01T18:37:51Z

I am uncomfortable with adding this to rustc, this clearly belongs in clippy for many reasons, not the least of which that I like pineapple in pizza.

estebank · 2020-04-01T18:41:10Z

+                        {
+                            for pineapple_segment in path.segments {
+                                if pineapple_segment.ident.name.as_str().to_lowercase()
+                                    == "pineapple"


This doesn't correctly interact with non_ascii_idents, it should also account for 🍍 and 🍕. For future compatibility it should probably also support 🍕ZWJ🍍.

Also account for people try to sneak things into the codebase with 🌲ZWJ🍎.

timClicks · 2020-04-01T18:43:29Z

This needs to be more general to justify inclusion imo. Perhaps it be possible to include the Linnaean taxonomy into the Rust type system somehow? That would allow taxa to specified unambiguously and could scale to include whole branches. Implementation is left as an exercise for the reader.

amanjeev · 2020-04-01T18:45:20Z

@estebank fork your own please

jdonszelmann · 2020-04-01T21:39:11Z

I think that it would be way easier to whitelist only certain pizza ingredients and combinations, instead of blacklisting pineapples. That way we could remove a lot of corner cases like the kiwi.

hollmmax · 2020-04-01T22:07:30Z

What happens if you transmute Pineapple to any other topping?
fn main() {
    unsafe {
        let topping = std::mem::transmute::<Pineapple, Topping>(Pineapple);
    }
    let pizza = Pizza(Topping);
}
One solution would be to forbid all instances of Pineapple. But I think the fruit market won't be happy with that decision
This would be undefined behavior, since Pineapple is not a Topping.

Pineapple is a valid Topping, just not for any food implementing the Salty trait.
Instead the problem is in the unsafe wrapping, he's just putting pineapples into tortillas, and pretending that's fine. Highly unsafe.

hollmmax · 2020-04-01T22:18:04Z

I think that it would be way easier to whitelist only certain pizza ingredients and combinations, instead of blacklisting pineapples. That way we could remove a lot of corner cases like the kiwi.

unacceptable, this would remove local ingredient, such as traditional cheese and salami, which did not gain international notoriety. Instead, we could disallow all ingredients implementing the Sweet trait, which would also prevent other abominations such as chocolate pizza.

randysecrist · 2020-04-01T22:33:54Z

I would like this feature in 30 minutes or less or I want my money back.

AZon8 · 2020-04-01T22:48:14Z

Unfortunately toppings are generally chosen at runtime, by the user, so a compile-time lint would catch almost nothing in practice.

Clearly, the only proper solution here is a full-blown effect system with dependent typing (and probably generic modules just to be sure), so we can statically verify that e.g. calling .sort() on a VecWithPineappleAtTheEnd turns into a VecWithPineappleWherever. That will definitely require an RFC. Or fifty.

I agree. Trying to prevent the user from constructing a logical error through identifying common patterns is a waste of time. Any solution should at least be able to solve the halting problem before we get half baked solutions like this.

My approach to this problem is set up as follows:

I'm exposing a Seed struct implementing a future that resolves to a Fruit enum.
A user can await it for multiple years. However, i plan to build my API such that when the plant is pending , i.e. planding, the API prevents the construction of a Pizza struct as this would allow the user to get a mutilated reference by unpinning the basis of a civilized world.

thefallentree · 2020-04-01T23:17:38Z

:triggered:

jvantuyl · 2020-04-02T01:01:27Z

Please add this! It’s the last thing stopping me from moving entirely to Rust from PHP! (We all know it really means Pizza Hates Pineapple, right?)
🚫 🍕 🍍

mark-i-m · 2020-04-02T01:23:57Z

I actually originally came to this thread expecting it to be about a parser change or something. I'm pretty sure the A-pizza label should be added.

ccfb3ee765a58cae · 2020-04-02T05:16:48Z

If we're going to have an option to #[allow(pinapple_on_pizza)], can we at least have pineapple_on_pizza.await!() syntax?

Havvy · 2020-04-02T07:18:52Z

This would break code showcased in Rustconf 2017: https://www.youtube.com/watch?v=wxPehGkoNOw&list=PL85XCvVPmGQhUSX_QBkxb4g1-o56cCqI9&index=7&t=527s

DutchGhost · 2020-04-02T09:14:36Z

what about people who write Pizza<Banana> ? Banana doesn't belong on Pizza either!

trondhe · 2020-04-02T09:46:57Z

Clearly unsound behaviour.

Daksh14 · 2020-04-02T11:01:23Z

We should be writing lints for various illegal toppings, them being on pizza should be UB

Pineapples
Bananas
Strawberries
Kiwis

ASAP.

nagisa · 2020-04-02T13:18:07Z

Now that entirety of the planet managed to survive April the 1st, closing.

JimLynchCodes · 2020-04-04T05:54:27Z

I agree with OP, but come on @Daksh14- kiwi pizza isn't that bad... in fact, I would propose kiwi pizza to be America's new pastime (since organized sports are a thing if the past now)!

mr-cheffy · 2024-06-05T15:12:26Z

Dear Pineapple Prohibition Committee,

Thank you for your meticulous review and subsequent rejection of the PR proposing a pineapple-free pizza policy in our source code. It seems our attempt to banish the tropical intruder has met with a resistance fiercer than a chef guarding his secret marinara recipe.

While our intentions were noble, aiming to protect the sanctity of traditional pizza toppings, we recognize that our efforts have been in vain. We accept that pineapple on pizza is a matter of personal taste, much like coding styles or preferred text editors.

We propose a truce. Let's embrace the diversity of pizza toppings as we do our coding languages. Whether you're a pineapple enthusiast or a purist, there's room for everyone at the pizza table. After all, it's the melting pot of flavors (and opinions) that makes our community so deliciously unique.

May our code remain as versatile as our pizza choices. 🍕🍍

Sincerely,
The Anti-Pineapple Pizza Task Force (Retired)

fgclue · 2024-10-22T18:16:39Z

We should be writing lints for various illegal toppings, them being on pizza should be UB
1. Pineapples

2. Bananas

3. Strawberries

4. Kiwis
ASAP.

Eat rust, strawberry on pizza is awesome.

fgclue · 2024-10-22T18:17:27Z

I mean rust, like, that thing, not the programming language.

forbid pineapple on pizza

55f908e

rust-highfive assigned estebank Apr 1, 2020

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 1, 2020

Centril reviewed Apr 1, 2020

View reviewed changes

jyn514 reviewed Apr 1, 2020

View reviewed changes

cuviper added the D-incorrect Diagnostics: A diagnostic that is giving misleading or incorrect information. label Apr 1, 2020

nagisa reviewed Apr 1, 2020

View reviewed changes

Centril added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Apr 1, 2020

kush-patel-hs approved these changes Apr 1, 2020

View reviewed changes

Aaron1011 reviewed Apr 1, 2020

View reviewed changes

estebank reviewed Apr 1, 2020

View reviewed changes

rochacbruno approved these changes Apr 1, 2020

View reviewed changes

wusyong approved these changes Apr 2, 2020

View reviewed changes

nagisa closed this Apr 2, 2020

emilyalbini deleted the nonstandard-taste branch April 2, 2020 13:18

joshtriplett added the april-1st Started on the 1st of April label Apr 2, 2020

cherryblossom000 mentioned this pull request Jan 22, 2022

Collection of interesting Code / Issue / PR liriansu-opus/liriansu-opus.github.io#2

Open

Uh oh!

Conversation

emilyalbini commented Apr 1, 2020

Uh oh!

killercup commented Apr 1, 2020

Uh oh!

dns2utf8 commented Apr 1, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

phansch Apr 1, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jcdyer Apr 2, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jamesmunns commented Apr 1, 2020

Uh oh!

Dexterp37 commented Apr 1, 2020

Uh oh!

kornelski commented Apr 1, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Dylan-DPC-zz commented Apr 1, 2020

Uh oh!

bjorn3 commented Apr 1, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

EvanCarroll Apr 1, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Ixrec commented Apr 1, 2020

Uh oh!

Dylan-DPC-zz commented Apr 1, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

amanjeev commented Apr 1, 2020

Uh oh!

bjorn3 commented Apr 1, 2020

Uh oh!

Centril commented Apr 1, 2020

Uh oh!

jebrosen commented Apr 1, 2020

Uh oh!

cuviper commented Apr 1, 2020

Uh oh!

Dowwie commented Apr 1, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Dylan-DPC-zz commented Apr 1, 2020

Uh oh!

kush-patel-hs left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

estebank commented Apr 1, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

timClicks commented Apr 1, 2020

Uh oh!

amanjeev commented Apr 1, 2020

Uh oh!

jdonszelmann commented Apr 1, 2020

Uh oh!

hollmmax commented Apr 1, 2020

Uh oh!

hollmmax commented Apr 1, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

phansch Apr 1, 2020 •

edited

Loading

jcdyer Apr 2, 2020 •

edited

Loading

kornelski commented Apr 1, 2020 •

edited

Loading

EvanCarroll Apr 1, 2020 •

edited

Loading

Dowwie commented Apr 1, 2020 •

edited

Loading

hollmmax commented Apr 1, 2020 •

edited

Loading

Daksh14 commented Apr 2, 2020 •

edited

Loading