Hi everybody,
I wanted to talk about this for a while now.
With the forum, I feel more able to communicate.
This pitch is a work in progress. There is no implementation at this time.
I look forward to hearing general feedback on this feature from the community.
Thanks,
-- Jeff
TLDR
Imagine that you have to use some third-party SDK like google analytics. You would have to sprinkle analytics code everywhere in your codebase. Imagine now instead of that you only have one file where all the analytics code of your app reside. This is what this feature is about decoupling cross-cutting concern like from your business code.
Compile time support for Aspect-oriented programming
- Authors: Jeffrey Macko
Introduction
This proposal aims at increasing code modularity by introducing some aspect-oriented programming (AOP) traits to the Swift language. AOP helps to unclutter code that otherwise tends to mix business logic with cross-cutting concerns.
Better separation could be achieved in Swift by injecting additional behaviors (code to be executed before or after some functions) at compile time into the existing source code. Thus adding code that is not central to the business logic of a program without cluttering the core code.
The main difference with AOP is that AOP is dynamic and this is static at compile time. And it will not support runtime injection like AOP because meta programming topics are out of scope.
Motivation
Traditional code tends to mix specific business code with cross-cutting concerns like profiling, instrumentation, logging, security, etc., ending up in cluttered code that is complicated to understand or refactor. Using AOP based injection, the code could better isolate those cross-cutting concerns from the business logic: the result is a better readable, maintainable code.
Most of the time the cross-cutting concerns are adding performance, error logging, managing access control or integrating third-party SDKs and you want to seek separation and independence from this code.
Avantages
The main advantages of this feature are:
- a definite improvement for the developer is to improve focus on a single concern
- readability and maintainability due to the separation of business logic code and cross-cutting concerns code
- increased productivity because it's easier to work on code in one central place rather than scattered over the project
- easily adding functionalities like instrumentation, profiling, logging, debugging, access controls, etc. without having to dive deep into the business code
- a warranty of execution even if the augmented function has complicated flows with several exit points
Use cases:
- add debugging information
- add profiling information
- add access control for increased security to several classes
- assert pre- and post-conditions
- add analytic metrics
- isolate calls to third-party code in a central place
- add generic behavior to code without modifying it like memoization
Background
This feature is heavily inspired by Aspect Oriented Programming although I don't think this is Aspect Oriented Programming per se but it carries a lot of similarities.
This feature is built to work at compile time like Codable and Equatable and Hashable conformance(SE-0185).
Separation of concerns is a big common problem in programming that Aspect Oriented Programming helps to reduce.
Other contributors already express the need for this
Other contributors have already expressed the need for this kind of feature on the mailing list Function Decorator sadly this thread doesn't get enough traction. I propose a different approach to fix the same issue. More recently Swift request list ask for Aspect Oriented Programming too.
Sourcery(a very popular metaprogramming toolkit for Swift) provide by default a template for doing it(Decorator.swifttemplate).
Other Languages Does It
Aspect-oriented programming is implemented in many languages.
Python decorator syntax PEP 318 – Decorators for Functions and Methods | peps.python.org / PythonDecorators - Python Wiki
Objective-C use of AOP
Analytics is a kind of cross-cutting concerns because an analytics strategy necessarily affects every part of the system. Analytics thereby crosscuts all classes and methods.
- Aspect-Oriented Programming and ARAnalytics - Artsy Engineering
- Hacking with Aspects - Peter Steinberger - ITT 2014 - Peter Steinberger - Architecting Modular Codebases - YouTube
Proposed solution
Teach the compiler how to insert code before/after and around an already existing function.
We propose that a function can have added code to it from an injector. We describe the specific conditions under which a function is augmented below, followed by the details of how the injector is implemented.
Introducing a new expression @decorator which injects code into a function. It can take the parameters before, after and wrap.
Expected behavior
| before | after | wrap |
|---|---|---|
| inject code at the beginning of the target function | after the before using defer with injected code |
be able to manipulate the input and the output of a target function by wrapping it in another function it will replace the original function with a new one that will be called instead and call the original function |
In the decorator code, you have access to self and all of the decorated function parameters, you can return or throws if you need to.
The decorator function:
- can be used anywhere
- can operate on any Swift function in a Class, Struct or Protocol implementation
- can only work on code that we have the source code of so it does not work on compiled library or frameworks
- cannot work for getter et setter on protocol
- we can inject before,after and wrap at the same time
- cannot work from a library
What the decorator feature needs to work:
- a way to operate (before|after|wrap)
- a way to hook onto another function that exists
- a priority of execution (optional by default the highest if more than two then propose a priority)
-
[unowned self]to do stuff - a way to retrieve a function original parameters
function-expression-parameters - the final function to call in wrap mode
New Compiler error/warning :
- raise an error when there is a conflict between the
prioritys and show where it has already been used - if the
function selectordoes not find a function to inject into, the compiler should emit a warning - will emit an error if used in
wrapmode and the function pass as the parameter is not used
The compiler will do most of the work so we will never have to see the generated version of the code unless we go into the pre-process representation in Xcode.
Detailed design
I am not set on the syntax yet. It's pseudo code.
Syntax 1 - More 
like
Pros against syntax 2 :
- the priority of calls is handled by the call order
- simple
- we can see where we inject code
@decorator(before|after|wrap, Class.AllFunction|Struct.AllFunction|Protocol.AllFunctionImplementation)
/// Example
/// FileA.swift
func decoratorBefore(x : Int) {
print("before")
}
func decoratorAfter(x : Int) {
print("after")
}
func decoratorWrap(x : Int, f : (x : Int) -> Bool) -> Bool {
print("wrap-b")
let val = f(x)
print("wrap-a")
return val
}
/// FileB.swift
@decorator(before, decoratorBefore)
@decorator(after, decoratorBefore)
@decorator(wrap, decoratorBefore)
func functionToDecorate(x : Int) -> Bool {
print("toto")
return false
}
Syntax 2 - More macro-ish like
Pros against syntax 1 :
- we don't need to modify the code where we do the injection
- it's way more generic
- the IDE(atom/emacs/xcode) should show that a function is decorated
@decorator(before|after|wrap) where <Class.AllFunction|Struct.AllFunction|Protocol.AllFunctionImplementation> priority 1-255 { [unowned self], <function-expression-parameters>, originalFunction : (<function-expression-parameters>)->()) in
<# Your Code #>
}
/// Example
/// FileA.swift
/// This will work **before** the function **B** in class **A**
/// have access to self of type **A**
/// **point** is the parameter of the function **B**
@decorator(before) where <A.B> priority 1 { [unowned self] (point : CGPoint) in
print("before")
}
/// This will work **after** the function **B** in class **A**
/// have access to self of type **A**
/// ** point** is the parameter of the function **B**
@decorator(after) where <A.B> priority 1 { [unowned self] (point : CGPoint) in
print("after")
}
/// This will work **around** the function **B** in class **A**
/// have access to self of type **A**
/// **point** is the parameter of the function **B**
/// **f** is the function **B**
/// you can have access to function **B** return value
@decorator(wrap) where <A.B> priority 1 { [unowned self] (point : CGPoint, f : (point : CGPoint) -> Bool) in
print("wrap-b")
let val = f(point)
print("wrap-a")
return val
}
/// FileB.swift
class A {
func B(point : CGPoint) -> Bool {
print("toto")
return false
}
}
Source compatibility
This is an additive proposal; existing code will continue to work.
Effect on ABI stability
This feature is purely additive and does not change ABI.
Effect on API resilience
N/A.
Alternatives considered
Using precedence name instead of priority
priority seems to be better understood by non-native English speakers.
Using #selector name instead of #decorator
Using #selector was my first idea, and it was a bad one because this does not do the same as the #selector and can be very confusing on what it tries to achieve.
Not having a priority
The priority help to order the injection of those code blocks.
Adding an @notdecorable
This keyword can be used like @objc, but this keyword prevents other to decorate your code.
If someone tries to decorate importantWork() he will receive a compiler error.
Bar.swift
class bar {
@notdecorable func work() {
print("bar is working...")
}
}
Adding an @decorable
This keyword can be used like @objc, but this keyword is necessary to allow other to decorate your code.
Decoration only works on function with this decorator.
Bar.swift
class bar {
@decorable func work() {
print("bar is working...")
}
}
) rather than macro.
and as explained in the pitch it will not support runtime injection like AOP because runtime meta programming is out of scope.
I'm terrible at explaining this feature.