Paul’s Swift wishes.md

1. Generalized existentials 😄 In progress!

   • Use case: implement Resource<T>, Siesta’s most obvious API design gap
   • Use case: silly dances like this

2. ✅ $0 ≠ all params

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

   • Use case: I specifically made the more-frequently used closure arg the second one here so that code referencing only it as $1 would compile (where it would not if it were $0)

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

   • Discussed on swift-evo but it’s sputtered?

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.

   • Use case: Siesta’s ResourceEvent should be ResourceObserver.event
   • Use case: RequestChainAction should arguably be Request.ChainAction, since it is tightly coupled to Request.chained(…)

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.

   • Use case: These properties are only used by this extension, and could be private to it.
   • Use case: This chunk would fit much more nicely in its own extension, with the props private.

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

    • Use case: log method

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 types ❌ Ruled 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

    • Use case: extension Entity: Codable where ContentType: Codable

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.