Chaque valeur de retour d'une opération doit être documentée. Comme pour les préconditions et les effets sur les arguments, cette description peut employer des mots de l'image mentale du type. L'opération pour dépiler une pile peut par exemple mentionner que la valeur de l'opération est le sommet de la pile.
Une telle description peut aussi mentionner d'autres opérations. L'opération pour empiler un élément sur une pile peut par exemple peut mentionner qu'après l'appel, l'opération qui détermine si la pile est vide renvoie faux.
Comme pour les arguments, un cas particulier se produit lorsque la valeur de retour est structurée, par exemple lorsque l'opération renvoie une liste ou un vecteur d'objets du type abstrait. Dans ce cas, la description doit indiquer si la liste ou le vecteur est fraîchement allouée par l'opération, auquel cas l'appelant est libre d'en faire ce qu'il veut, ou au contraire si la liste ou le vecteur fait potentiellement partie de la représentation interne de l'objet du type abstrait.
Un exemple de cette situation est un type abstrait voiture qui stocke en particulier une liste des roues. Une opération permettant de récupérer la liste des roues de la voiture a deux possibilités: soit renvoyer cette liste directement et risquer que l'appelant la modifie de manière destructive après l'appel doit renvoyer une copie de la liste.
Il est bien sûr plus prudent de systématiquement renvoyer une copie, mais c'est aussi relativement coûteux, en particulier si l'appelant n'a pas l'intention de s'en servir de manière destructive. Pour cette raison, il est courant de renvoyer la liste interne et de documenter ce fait dans la description de l'opération.