From a75c766f80126525e8dfa525b32252ba38b17b26 Mon Sep 17 00:00:00 2001
From: Andreas Baumann <mail@andreasbaumann.cc>
Date: Sat, 30 Oct 2021 20:54:23 +0200
Subject: cc: some proper checking of return types and some primitive check for
 missing or superflous return statements

---
 miniany/README.html | 8 ++++++++
 1 file changed, 8 insertions(+)

(limited to 'miniany/README.html')

diff --git a/miniany/README.html b/miniany/README.html
index ca5cdf7..c40d9f8 100644
--- a/miniany/README.html
+++ b/miniany/README.html
@@ -263,6 +263,14 @@ cat c4.c4 EOF c4.c EOF cc.c EOF hello.c | ./c4
 <ul>
 <li>Don't allow non-blocked if/else, just avoid then dangling else problem, it's uninteresting and in C not as bad as in PASCAL-like languages, as the block markers are just one character big.</li>
 </ul>
+<h3>Return statement</h3>
+<p>Implemention status: yes, but..</p>
+<p>Reasoning:</p>
+<ul>
+<li>There are good reasons not to allow <i>return </i>everywhere in the code, see newest Oberon revisions allowing <i>RETURN </i>only at the end of the function declaration. There are benefits like easier detection whether the function returns a function, easier flow analysis (image <i>returns </i>in complicated <i>if-else</i>-statements). For now we allow it everywhere, but we should try hard not to use it in the middle of code blocks.</li>
+<li>There is an argument from the code correctness point of view as <i>return </i>in the middle of code makes the code hard to reason about (similar to too many if-else-statements)</li>
+<li>Error handling is really hard, for now we check only whether we see a <i>return </i>at all anywhere in the body.</li>
+</ul>
 <h3>Register Allocation</h3>
 <p>Implementation status: yes</p>
 <p>Reasoning:</p>
-- 
cgit v1.2.3-54-g00ecf