README: add missing static_asserts

README.md

@@ -558,20 +558,24 @@ We take [this C++ Core guideline](http://isocpp.github.io/CppCoreGuidelines/CppC
 
 Because we want (non-unique) class instances to behave roughly as class instances do in Python (that is, to be "maybe retained" when passed as parameters), we make this core guideline advice the implicit default for untyped/generic params and params of explicit class type. For example, `x` and `y` are both passed to `func` by const ref in this example:
 
-```
-
+```python
 class (Foo:
     pass
 )
 
 def (func, x, y: Foo
-    # TODO static_assert both passed by const:ref
+    static_assert(std.is_reference_v<decltype(x)>)
+    static_assert(std.is_const_v<std.remove_reference_t<decltype(x)>>)
+    static_assert(std.is_reference_v<decltype(y)>)
+    static_assert(std.is_const_v<std.remove_reference_t<decltype(y)>>)
+    static_assert(std.is_same_v<decltype(y), const:std.shared_ptr<const:Foo.class>:ref>)
 )
 
 def (main:
     x = Foo()
     y = Foo()
     func(x, y)
+    func(1, x)
 )
 ```
 
@@ -583,6 +587,22 @@ Note however that we don't entirely embrace the suggestions of this core guideli
 
 If passing by T* or T& suffices in C++ (especially const T&), maybe you should be using `struct` instead of `class` in ceto anyway! And note that switching class to struct doesn't require changing a whole bunch of `x->foo` to `x.foo` as would be the case in C++ (the annoying assymetry of `x->foo` vs `x.foo` being one of the better reasons to embrace R.36 fully in non-ceto generated C++ code). Yes, flounting this suggested warning results in code that unnecessarilly requires a parameter ownership regime (shared_ptr) when unowned raw pointers or mutable references suffice. But this is a reasonable performance compromise for safety purposes (see Chrome's banning of all raw pointers in favor of miracle_ptr).
 
+Note that for classes with "uninitialized" data members
+
+```python
+class (Foo:
+    x: Foo
+    y: Foo
+)
+
+def (main:
+    x = Foo(None, None)
+    Foo(x, x)
+)
+```
+
+the generated C++ contains a 2-arg constructor taking x and y as by value shared_ptrs and initializing the data members via std::move in the initializer list. It is debatable whether a future optimization should be added to ceto so that parameters of ceto-class type used only once are taken by value but std::moved to their destination (it further complicates the meaning of ```Foo``` and may require some kind of ```export``` keyword (perhaps the existing ```noinline``` can be used) given our current support for forward function declarations).
+
 ## Gotchas
 
 ### Implicit Scope Resolution