user161: In the docs about validators a function named unstableMakeIsData is used, but has the following comment:
-- 'unstableMakeIsData' is a TemplateHaskell function that takes a type name and
-- generates an 'IsData' instance definition for it. It should work for most
-- types, including newtypes and sum types. For production usage use 'makeIsDataIndexed'
-- which ensures that the output is stable across time.
unstableMakeIsData ''Date

It seems inconvenient to have code that needs to be changed for production so I'm curious why this is required. For example, why not just use makeIsDataIndexed in development too? What benefit does unstableMakeIsData have?
I tried searching for both function names across the docs, but the only instances are in two different comments along these same lines.

user801: If you take a look at the code you can see that makeIsDataIndexed takes 2 arguments (datatype and mapping) but unstableMakeIsData takes only 1 argument, so it's faster to use (that's why it's used in examples)

Usage example:
PlutusTx.makeIsDataIndexed ''Action [('Deposit,0),('Choice,1),('Notify,2)]

With unstableMakeIsData it would look like this:
PlutusTx.unstableMakeIsData ''Action

You can find more context in this commit as well. Note, that unsafeMakeIsData was later renamed to unstableMakeIsData.
The old `makeIsData` would encode/decode based on the ordering of the
constructors, which isn't stable. We *need* this to be stable across
time, since tools other than our Haskell programs might be producing
datums/redeemers (e.g. CBOR tools in other languages), so we really
don't want this to change unexpectedly.

So we avoid it everywhere. The exception is the usecases: they're just
examples so it's fine for them to be unstable.

Marlowe is probably the most annoying, but I think we *do* care about
the Marlowe types being stable!


161: <p>In <a href="https://plutus.readthedocs.io/en/latest/plutus/tutorials/basic-validators.html" rel="nofollow noreferrer">the docs about validators</a> a function named <code>unstableMakeIsData</code> is used, but has the following comment:</p>
<pre><code>-- 'unstableMakeIsData' is a TemplateHaskell function that takes a type name and
-- generates an 'IsData' instance definition for it. It should work for most
-- types, including newtypes and sum types. For production usage use 'makeIsDataIndexed'
-- which ensures that the output is stable across time.
unstableMakeIsData ''Date
</code></pre>
<p>It seems inconvenient to have code that needs to be changed for production so I'm curious why this is required. For example, why not just use <code>makeIsDataIndexed</code> in development too? What benefit does <code>unstableMakeIsData</code> have?</p>
<p>I tried searching for both function names across the docs, but the only instances are in two different comments along these same lines.</p>
 801: <p>If you take a look at the <a href="https://github.com/input-output-hk/plutus/blob/master/plutus-tx/src/PlutusTx/IsData/TH.hs#L55" rel="noreferrer">code</a> you can see that <code>makeIsDataIndexed</code> takes 2 arguments (datatype and mapping) but <code>unstableMakeIsData</code> takes only 1 argument, so it's faster to use (that's why it's used in examples)</p>
<p><a href="https://i.stack.imgur.com/jpliS.png" rel="noreferrer"><img src="https://i.stack.imgur.com/jpliS.png" alt="enter image description here" /></a></p>
<p>Usage example:</p>
<pre><code>PlutusTx.makeIsDataIndexed ''Action [('Deposit,0),('Choice,1),('Notify,2)]
</code></pre>
<p>With <code>unstableMakeIsData</code> it would look like this:</p>
<pre><code>PlutusTx.unstableMakeIsData ''Action
</code></pre>
<p>You can find more context in this <a href="https://github.com/input-output-hk/plutus/commit/b55b251a30f3238d11c0eede13d31b51d1e745d0" rel="noreferrer">commit</a> as well. Note, that <code>unsafeMakeIsData</code> was later renamed to <code>unstableMakeIsData</code>.</p>
<pre><code>The old `makeIsData` would encode/decode based on the ordering of the
constructors, which isn't stable. We *need* this to be stable across
time, since tools other than our Haskell programs might be producing
datums/redeemers (e.g. CBOR tools in other languages), so we really
don't want this to change unexpectedly.

So we avoid it everywhere. The exception is the usecases: they're just
examples so it's fine for them to be unstable.

Marlowe is probably the most annoying, but I think we *do* care about
the Marlowe types being stable!
</code></pre>
