Skip to content

Instantly share code, notes, and snippets.

@pcantrell
Last active May 19, 2022 15:19
Show Gist options
  • Save pcantrell/208f26bdbe21b1134309cc7706dda5cb to your computer and use it in GitHub Desktop.
Save pcantrell/208f26bdbe21b1134309cc7706dda5cb to your computer and use it in GitHub Desktop.
  1. Generalized existentials 😄 In progress!

  2. $0 ≠ all params

  3. Fix anonymous closure argument goofiness (bug, older bug)

  4. Static dispatch + extensions = confusion (Ghost of Swift Bugs Future)

  5. Allow enums nested in generic types

  6. Types nested in protocols not allowed

    Would be useful for keeping types (esp enums) that are tightly coupled to a protocol out of the global namespace.

  7. Stored props in same-module extensions (partial types)

    I mostly have in mind extensions keeping stored props private to the few methods that need them. There’s discussion that this could even work across modules, but that’s a much bigger, thornier question.

  8. Help breaking retain cycles in closures

    No specific killer solution to propose here. Just an area where it’s too easy to cause problems, and seems like the language could help more than it currently does.

    • Use case: resource.addObserver(owner: self, observer: self.fooChanged) causes a retain cycle that is not at all obvious. Would love for Siesta to flag it for users, but the compiler doesn’t give the library a way to do so.
  9. self.someMethod that captures weak self

    • Use case: The correct solution to the item above is resource.addObserver(owner: self) { [weak self] self?.fooChanged($0, $1) }, which is clumsy as all heck
  10. varargs autoclosures

  11. Lens/ref/inout var to avoid repeated mutating refs deep into structure 🙂 Partially mitigated by keypaths

  12. Weak-reference-dependent objects

    Ability to say “notify me when this particular weak ref is deallocated,” or alternatively “when X is deallocated, release Y as well, even though X does not directly reference Y.” Siesta simulates this manually, and it’s not ideal.

  13. Implement protocol multiple times w/diff typesRuled out by stated plans not to allow generic protocols, because the whole point of assoc types is they can’t have multiple conformances

    • Use case: Multiple conformances to ResourceObserver<T> that each take a different T in their Resource<T> arg, which would allow Siesta to dispatch model-typed observers to model-specific handling code
  14. $parameters / tuple splatting 🤞 Variadic generics might being laying a foundation for this

  15. Open enum-like switchable structure

    Superficially similar to non-frozen enums, but let other modules add their own cases via extensions. Siesta already handles this in a manner similar to the one described in SE-0192’s appendices, and doing so requires no new language features. However, it would be nice to have a standard library protocol for this so that Siesta doesn’t have to define its own “public but please don’t use it” protocol, and language support so Siesta didn’t have to provide string args that redundantly repeat the case names.

  16. Members that are private but exposed to a specific protocol conformance

    POP is limited by the fact that every member used by a proto extension must be as public as the protocol itself, so e.g. a public Observable protocol that relies on a collection of observers needs the raw observer collection itself to be public

  17. Warn when setter does not use newValue

  18. Allow conditional conformance extensions to synthesize Codable conformance

  19. Allow keypaths to reference functions, not just properties

    KeyPath’s value type would be a closure.

    • Use case: Would allow resource.addObserver(owner: self, observer: \.fooChanged) that doesn’t create a retain cycle as self.fooChanged does (see items 8 and 9 above)
  20. More fluent & flexible pattern matching

    The if case syntax still makes me twitch, and the fact that it’s not a boolean expression leads to many an awkward conditional.

  21. Subscripts that throw

    This use to be only a minor irritant, but will seriously compromise dynamic member lookup, which in many situations ought to throw.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment