github.com/ipld/go-ipld-prime@v0.21.0/schema/gen/go/README_behaviors.md (about)

     1  Behaviors of Generated Types
     2  ============================
     3  
     4  Types generated by `gogen` obey the rules that already exist for the IPLD Data Model,
     5  and the rules that exist for Schema typed nodes.
     6  
     7  There are some further details of behavior that might be worth noting, though.
     8  
     9  Some of these details aren't necessarily programmer-friendly(!),
    10  and arise from prioritizing performance over other concerns;
    11  so especially watch out for these as you develop against the code output by this tool.
    12  
    13  ### retaining assemblers beyond their intended lifespan is not guaranteed to be safe
    14  
    15  There is no promise of nice-to-read errors if you over-hold child assemblers beyond their valid lifespan.
    16  `NodeAssembler` values should not be retained for any longer than they're actively in use.
    17  
    18  - We **do** care about making things fail hard and fast rather than potentially leak inappropriate mutability.
    19  - We do **not** care about making these errors pretty (it's high cost to do so, and code that hits this path is almost certainly statically (and hopefully fairly obviously) wrong).
    20  
    21  In some cases it may also be the case that a `NodeAssembler` that populates the internals of some large structure
    22  may become invalid (because of state transitions that block inappropriate mutability),
    23  and yet become possible to use again later (because of coincidences of how we reuse memory internally for efficiency reasons).
    24  We don't reliably raise errors in some of these situations, for efficiency reasons, but wish we could.
    25  Users of the generated code should not rely on these behaviors:
    26  it results in difficult-to-read code in any case,
    27  and such internal details should not be considered part of the intended public API (e.g., such details may be subject to change without notice).
    28  
    29  ### absent values
    30  
    31  Iterating a type-level node with optional fields will yield the field key and the `datamodel.Absent` constant as a value.
    32  Getting a such a field will also yield the `datamodel.Absent` constant as a value, and will not return a "not found" error.
    33  
    34  Attempting to *assign* an `datamodel.Absent` value, however --
    35  via the `NodeAssembler.AssignNode` function (none of the other function signatures permit expressing this) --
    36  will result in an `datamodel.ErrWrongKind` error.
    37  
    38  // Seealso some unresolved todos in the [HACKME_wip](HACKME_wip.md) document regarding how absent values are handled.