Skip to content

Instantly share code, notes, and snippets.

@erica

erica/AltTOC.md

Last active April 12, 2018 16:44
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save erica/9eae0d949297509ad86e to your computer and use it in GitHub Desktop.
Save erica/9eae0d949297509ad86e to your computer and use it in GitHub Desktop.
Download ZIP
Raw
AltTOC.md

More Swift Stuff

See Also: Active Material

Accepted

Redirected to bug report

Rejected

Done

Non-final forms for active work

Evolved Into Accepted

Dead Just Dead

  • Introducing StaticSelf, an Invariant Self Update: we will not propose this formally. See resolution section.
  • Optional collections Dmitri Gribenko says no higher kinded types
  • Other debug constants for debug/release, full context, #symbol, #mangledname, #context, #debugcontext, #releasecontext, #filename. Function returns a string, not a gregor name Chris L.: defer or unnecessary, consider using relative path universally
  • final expression shortcuts: no return statements, no branching Per Jordan Rose, I will live with typing return.
  • Scala-style Wildcard currying See this
  • SE-XXXX Requiring Proactive Overrides for Default Protocol Implementations Draft on list 4/28
  • Adding yes/no and on/off as standard alternatives to true/false: Discussed on list 5/4/16
  • * Introducing an error-throwing nil-coalescing operator Just use guard let
  • Introduce a #fileName identifier Pitched on-list List prefers to give relative path in place of #file but not add new identifier.
  • SE-XXXX Introducing a striding(by:) method on 3.0 ranges, nearly ready for pull request and collection types. Ping group for status
  • I have a vested interest in Yong hee Lee's Anonymous Enumerations and would like to see this expanded as well to option flags. On list: http://thread.gmane.org/gmane.comp.lang.swift.evolution/19210 5/31/16, recent revision in June
  • Rationalizing Swift's take/drop/first/last/sequence
  • Decoration: add behavior through extension, not just replace behavior - lateral inheritance, available to subclasses (see problems with non-final)
  • Struct inheritance, Enum inheritance (almost anti-inheritance). JRose writes: "I’m pretty sure one of the reasons is because inheritance implies method inheritance, which implies being able to override methods, and that opens a big can of worms which will be familiar to any experienced C++ programmers. Swift struct methods aren’t dynamically dispatched; they’re just function calls. But if you could subclass a struct and override methods, then the methods would need to be dynamically dispatched … but that implies that structs would need to contain vtables (or isa pointers), which makes them a lot more heavyweight. Or on the other hand, if struct methods stayed statically dispatched, then overriding them would be fraught with peril, for the same reason that overriding nonvirtual methods in C++ is generally a very bad idea." Dave Reed writes, "Inheritance isn't really compatible with value types at least if they're allocated on a stack (known as "stack-dynamic) and take a fixed amount of space (think about what would happen if you assigned it to a subclass that had additional data - no room to store the additional data). References are typically stored on a heap with a pointer to the object stored on a stack (pointers takes the same amount of memory no matter what type they point to). If you don't need extra data (additional instance variables), you can add new methods to CGRect using extensions."
  • Disambiguating SPM Naming Conflicts. Pull request here Needs reworking, revision to deal with module differentiation, origin declaration, etc. See swift-build-dev list Split, defer to after Swift 3
  • Extending striding(by) to collections
  • Revisiting Build Namespacing Update: going nowhere again. Surely there has to be an elegant build graph solution that allows modules to use sensible names
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment