I7 bug

In I7 if you make a countainer edible and there is something inedible in the container, if you eat the container, you eat the other (inedible) thing to. :astonished:

I wouldn’t classify this as a bug. I7’s eating action is deliberately simple, because it’s a basis for you to build on. If you’re going to do wacky stuff like edible containers, it’s your responsibility to decide how that should work.

Edible containers could be a concept for a mini-comp. There are possibilities…

If Kinder eggs are any indication, this should be a localisation issue: if American dialect is used, eating an edible container containing an inedible thing should make you die. Otherwise, the inedible thing just moves to your inventory.

Also, drinking hot beverages could be fatal.

In any case, it’s not hard to fix this “bug”, e.g. like this:

"Yummy Cardboard" by Vyznev Xnebara

The Pantry is a room.

A white cardboard box and a brown cardboard box are edible containers in the pantry.

Some cookies are in the white box.  The cookies are edible.


The list of found things is a list of things that varies.

Carry out eating a container:
	now the list of found things is the list of things in the noun;
	now all things in the noun are carried by the player.
		
Last report eating a container when the list of found things is not empty:
	say "You find [list of found things with indefinite articles] in [the noun].".


Test me with "eat white box / eat brown box / eat cookies".

It seemed like a bug

There are a lot of situations that IF interpreters doesn’t interpret like the programmer think is natural.
Firstly, it often makes sense to put a condiment like inedible mustard in a sandwich and then eat the sandwich without complaint. It also makes sense to put poison in food, whether other actors are doing it to your food or you doing it to an actors food. When you can’t tell if Inform should allowed it or not, you leave it up to the programmer to decide what happens (by including something like "Instead of eating a container which contains something inedible, say “No, you can’t.” instead).
Secondly, a lot of these situations are too complicated to predict without writing a bloated framework. The Inform manual describes a scenario where the player circumvents an obstruction by getting in a box, and telling another actor to push the box in that direction. Yes, if you need this framework, you should make it, but it would bloat all IFs that didn’t need it.
Thirdly, Inform is pretty primitive at places. Did you know that crossing an enterable chest counts as entering it? When you start looking for unnatural things, you can find all sorts of things. That’s why there’s extensions and extension libraries.
It only becomes an actual bug if the interpreter either starts sending you error messages. (Try “purloin all / i / drop all”, for example.) I encountered a bug where the error messages themselves were corrupted (which I believe was fixed shortly after). Those are what actual bugs look like.

Well, sort-of; I’m afraid that that perspective might encourage people to not always ask when they run into fishy behavior. While it’s true that error messages almost always indicate a bug, a bug need not imply error messages, so we generally use the official documentation to distinguish correct and faulty behavior. On bug 788, for instance, gnomon had no errors to report, but did cite two instances where the WI examples suggested a disagreement with the compiler. This case, however, falls under documented limitation'' rather thanbug’’ because the Standard Rules’ specification says that there are only two conditions on eating: that the noun be edible and that it be held—the edibility of sub-objects is not a listed criterion.