+- transparent fields, parameters which are structs or pointers
+- transparent fields which are arrays
+- transparent results from functions to have same effect as inline-results
+- manifest values for records: [.foo = a, .bar = b]
+- manifest values for arrays: [expr = expr, ...]
+- constant structure definitions
+- const structures can inherit from another, and update select fields.
+- 'use' labels *must* appear in case statements.
+- 'then' can extend a case section into some other.
+
+### And then ...
+- constructors(called by @new) and destructors (called by @free)
+- "?type" which includes an error flag in the type
+- interfaces - with syntax for function type declarations, including
+ type parameterisation
+- const arrays that are extended incrementally
+- enums that are extended incrementally
+- enum as array index. foo:[:enum]int. foo[.baz] = 23
+- modules - exported names in versions, and import lists
+ on types, fields, constants, etc
+- foreach variable-list := make_generator() do
+ A generator has 'first', 'next' and 'finally' methods
+ 'first' and 'next' return the same type which is conditional ('?' works)
+ 'finally' returns some other type - possibly Tnone - which goes to
+ a set of case at end of loop
+ NOTE need to understand how break/continue are handled.
+- lamba - inline functions. If possible allow a syntax that looks like 'while'...
+- "run" statement which copies things to a new frame and runs in
+ parallel. It has no 'return' value
+
+### static analysis
+- add generic attributes with rules for what values are allowed with
+ which attributes. Need to track:
+ - when object should be freed
+ - when ref is NULL
+ - when value is valid
+ - when int is in some range
+ - when object is "locked"
+ structures can have virtual 'state' fields which align with attributes
+ and certain state values imply certain attributes.
+
+### export
+- structs which have endian and are not sorted (records)
+- interface to C api (FFI)
+
+### escape
+- for an attribute
+- convert between integers and refs.
+
+### compile time reflection
+- code that can interpret attributes etc??
+
+## Needs Design
+- review {} syntax issues - look at weird test cases
+- do I need a 'rune' type? What are the elements of a string?
+ Are they small strings? Can I convert to codepoint by treating as number?
+ How much of this is in the utf8 library? Can a string literal be a number?
+- exactly where does auto enref/deref happen?
+ .foo modifier does auto-deref
+ (args) modifier does auto-deref (if that makes sense)
+ assignments does auto-enref
+ function parameter passing does auto enref and auto deref
+
+ general operators? Not comparison. Not test. Probably not anything.
+
+- can "A if B else C" have "A" and "C" be different - one a ref and one not?
+ This might make sense if a ref was wanted - an lvalue is then accepted.
+ But then the ref can have '@' applied so it becomes an lvalue. So "no".
+
+- ? modifier for type makes "no such value" an option, detected by '?' operator
+- $ operator to convert to ?number from ... ref? enum?
+ ?$"hello" can test if the conversion would work. '$foo ?? default'
+ provides a default value
+- a suffix on a number/string can provide soft typing which is interpreted
+ in type context. Must like .enumvalue is interpreted only the context of
+ expected type, '43i' would only be meaningful in the same context.
+- const arrays that are initialized incrementally throughout the code,
+ and post-processed at compile-time, e.g. to sort or derive LR tables.
+ Maybe even across modules.
+ Need a syntax
+ Maybe 'const' can be followed by name of a const which forms the namespace.
+ So a struct bar containing x and y could be initialized
+ const foo::bar
+ x ::= 1; y::=2
+ Then an array could be extended with [+]
+ const ra[+]
+ x::=2 ...
+
+ The syntax needs to be clearly different from
+ const a::num=1; b::=2
+ if that is still allowed
+ Maybe the '=' is enough to differentiate
+
+- IN and OUT should not be completely ignored when not expected.
+ As well as causing NEWLINE to be ignored, there should be some
+ balance requirement. Some productions should be required to be
+ balanced. Lists should not have gratuitous indents.
+ Revisit everything I considered before, but now consider it only
+ for ignore IN/OUT.
+
+- "debug" code that can be compiled out. For code, "if debug" is enough
+ if the const can be set easily. For structure members a 'debugonly'
+ attribute needs to be handled. Of course 'debug' is multifaceted.
+ We might want tracing, consistency, profiling, etc.
+
+- union types - how do I want to support these? inheritance with variance?
+- how are mixins represented?
+- lambda
+- 'error' value for various types. NIL for pointer NaN for float, extra flag bit
+ for integers. -MAX_INT ??