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

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"?

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

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

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.

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

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.

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

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 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.

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

I don't believe we allow negative cost abstractions.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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?)
🚫 🍕 🍍

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.

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

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

Clearly unsound behaviour.

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.

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

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

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)

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.

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