0.2 pain points in 0.1

• Explicit conversions, everywhere
  • Especially bad with lambdas, integer literals, and String/StringConstant and Vector/Array
  • Potential solutions:
    • #102 - declare converter ops for function arguments
    • Implicit construction for functions with declared return types
• Overload linearization is broken
• Compile-time programming is weird
  • static is weird and verbose
  • Static strings aren't strings; have awkward-to-use singleton types
  • Can't effectively use dynamic sequences
    • But compile-time malloc/free would be kind of bananas
  • Some POD types are broken with compile-time evaluation due to dependence on memcpy/memmove
  • No good way to report custom errors
  • Lack of SFINAE
• No const/immutability control
  • Potential solutions (in order of complexity):
    • C-style idiot const
    • D-style const/immutable
    • Cyclone/Deca/Disciple-style region types
      • Region types would also help with use-after-free and alias analysis
• Library
  • Iterators are designed wrong, should look like D ranges
  • Everything is dumped into prelude by default
  • No way to disable default lib-clay search path entirely
  • General organization, convention, style mishmash issues
  • Missing libraries
    • Threading
    • Type-safe atomic/locked reference
    • Decent testing
    • More containers
• Language warts
  • Can bind variadic patterns or arguments, but not variadic variables?
  • foo(x): y -> { ... } :: z -> { ... } syntax is goofy
  • Literal suffixes are goofy
  • eval statements and exprs, but not toplevel definitions
  • Can pattern-match compile-time values, but not runtime values?
  • Variants are different from enums
  • Variants are weird compared to traditional HM sum types
  • Dynamic dispatch is weird and underspecified
  • No mechanism for statically initializing
  • Operator function and primitive interfaces are too ad-hoc
• Misc useful features
  • Python-style keyword arguments
  • Default arguments