Boring introduction/context

Today's snapshot 19w38a brought a very useful data pack feature: predicates. They enable you to check lighting, weather, stats, and do RNG and complex nested checks. However, this inclusion further highlights an accessibility issue with all the fancy data-driven files: regular commands are falling further behind.

Setting up a data pack with files can be inconvenient, or outright impossible if the player lacks the technical skill or just wants to test somewhere they don't have file system access. When someone wants to make something with commands, inert files shouldn't be a prerequisite for certain techniques, especially when those techniques seem less complex than things that don't require them (e.g. you can check the exact contents of an inventory with commands alone, but you need a data pack to check the weather?)

The actual suggestion: anonymous data

My proposal is the ability to insert predicates and loot tables directly into the command, as an alternative to using the resource location name. Here are a few examples:

/execute if predicate {"condition":"location_check","predicate":{"light":{"light":{"min":15}}}} run say it's bright

/loot give @p loot {"pools":[{"rolls":1,"entries":[{"type":"item","name":"dirt"}]}]}

/summon cow ~ ~ ~ {DeathLootTable:'{"pools":[{"rolls":1,"entries":[{"type":"item","name":"cow_spawn_egg"}]}]}'}

It's basically an "anonymous" piece of data. Obviously these commands could get pretty large, but most real projects would ignore this in favor of the current named references. The convenience for testing is nice, but the main benefit of this feature would be enabling users to access data even when they can't access a data pack.

Alternative: generating data

This alternative way might be easier, not sure how I feel about it though.

Since structure blocks can currently be used to create data in a fake "generated" data pack, possibly a command could be added to create and write other kinds of data to this false pack.

/generate loot_table cool:table {"pools":[{"rolls":1,"entries":[{"type":"item","name":"pufferfish"}]}]}

/generate predicate cool:predicate {"condition":"location_check","predicate":{"light":{"light":{"min":4}}}}

It would save in the same way structure blocks do, and from there the specified name could be used in other commands. Either of these solutions would solve the issue of data accessibility in my opinion. Advancements and recipes don't really make sense to have anonymous, but they could be included this way I suppose.