Over time, I hope to add some or all of the following:

• Semantic features: Given that The Semel Editor (TM) has 100% of your program's semantics in it, it could:
  • add reflection
  • find all semels that match a pattern
  • identify all constraints on a particular template, based on usage
  • identify all templates which satisfy a set of constraints
  • identify which exceptions could be thrown during the invocation of this expression/statement/function
  • identify which #include directives must be added because they provide something that is used in that translation unit
  • identify which #include directives could be removed because they don't provide anything that is used in that translation unit
  • identify which names (e.g. functions, types, variables) are never used
  • perform inter-procedural data flow analysis
  • perform inter-procedural control flow analysis
  • perform type-inference of variables from usage
• Integrated development environment features: Given that The Semel Editor (TM) is similar to the front-end of a compiler (i.e. it ends up with semels, which are similar to a compiler intermediate language), it could:
  • add a class browser
  • add a code-generator (i.e. the back-end of a compiler)
  • add a debugger
  • add incremental compilation
  • add an interpreter
  • add a formatter/pretty-printer (e.g. allow you to specify an indenting style)
• Support for Design Patterns
• Support for Refactorings
• Support for things you wish you could say in C++, but currently cannot:
  • a class is an interface
  • a class is clone-able
  • a class is either abstract or concrete
  • a class is either reference-semantics or value-semantics
  • a class is immutable
  • a class is not default-constructible (e.g. what is the "default" social security number?)
  • a non-virtual function cannot be overriden
  • a virtual function cannot be overriden (but now you can say that in C++ with "final").
  • access control lists (i.e. replace "public", "protected", "private", and "friend" with a list of which semels can access which members)
  • when you add a data member, you would have to specify:
    • how is that data member initialized?
    • how is that data member copied?
    • how is that data member assigned?
    • how is that data member tested for equality?
    • how is that data member cleaned up (e.g. during assignment and destruction)
    • how is that data member converted to a string (e.g. Java toString())
  • all constructors, copy constructors, assignment operators, and destructors could be synthesized from the above
• Support for things you wish you could say in Java, but currently cannot:
  • a function or variable is "const" (i.e. read-only)
• Support for enforcing style guidelines
  • all abstract classes have protected constructors
  • all abstract classes have protected copy constructors
  • all abstract classes have protected assignment operators
  • all abstract classes have public virtual destructors (if they are used as ": public" base classes)
  • all constructors invoke all base class constructors
  • all constructors invoke all data member constructors
  • no goto statements
  • no pre- or post-increment operator as an operand of an expression (i.e. it must be the top-most operator)
• Support for more clarity of intent when it comes to passing parameters into and out of a function
  • by-value (e.g. "int x")
  • by-pointer (e.g. "int * p")
  • by-pointer-to-const (e.g. "const int * p")
  • by-const-pointer (e.g. "int * const p")
  • by-const-pointer-to-const (e.g. "const int * const p")
  • by-lvalue-reference (e.g. "int & r")
  • by-lvalue-reference-to-const (e.g. "const int & r")
  • by-rvalue-reference (e.g. "int && r")
  You could specify if the parameter is "read-only", "read-write", or "write-only", and The Semel Editor (TM) could choose the best alternative from the above set.
• Support for C#
• Support for Java